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ABSTRACT 


Current  corrective  maintenance  practices  in  U.S.  Navy 
ships  follow  troubleshooting  guides  found  in  the  paper  copies 
of  technical  manuals.  These  manuals  are  often  difficult  to 
find,  maintain,  and  store,  and  guides  are  not  easily  followed. 
An  expert  system  for  troubleshooting  could  improve  current 
practices  by  providing  a  centralized  program  that  is  easily 
maintained  and  followed.  By  coupling  to  a  database  of 
procedures,  the  precise  steps  to  correct  the  problem  could 
also  be  called.  An  expert  database  system  allows  an  expanded 
knowledge  base  that  is  easily  modified  while  maintaining  the 
integrity  of  the  expert  system  program. 

A  prototype  system  for  troubleshooting  the  NAXI  100-2  Low 
Pressure  Air  Compressor  was  developed  to  illustrate  the 
advantages  of  expert  database  technology  in  this  application. 
VP-EXPERT  and  DBASE  IV  were  used,  and  the  prototype  as 
demonstrated  to  SIMA,  San  Diego,  was  received  favorably. 
Conclusions  drawn  supported  the  feasibility  of  such  systems  to 
assist  in  the  performance  of  shipboard  maintenance. 
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I .  INTRODUCTION 

A.  BACKGROUND 

Within  the  warships  of  today' s -  modern  US  Navy  the 
effective  corrective  maintenance  of  main  propulsion  and 
auxiliary  machinery  requires  a  vast  array  of  technical 
expertise  and  written  reference  material.  Other  than  the 
supply  functions  on  SNAP  II  (an  installed  minicomputer  for 
administrative  support)  equipped  ships,  troubleshooting  and 
repairs  are  completely  manual,  and  often  imprecise  or 
misdirected.  Some  specific  problems  are  as  follows: 


1 .  The  expertise  of  technicians  varies  widely  from  ship 
to  ship  and  from  sailor  to  sailor.  The  more  senior  petty 
officers  and  chief  petty  officers  show  a  wide  range  of 
experiences  and  knowledge.  Even  when  specifically  trained 
and  coded  for  a  certain  class  of  ship  or  machinery,  levels 
of  expertise  are  far  from  standard. 

2.  Current  troubleshooting  practices  rely  heavily  on  a 
plethora  of  technical  manuals,  PMS  (planned  maintenance 
system)  cards,  owner's  manuals,  or  pass  down  notes  and 
checklists.  All  this  paper  u.ss  not  hold  up  well  on  the 
deckplates,  and  important  pages  are  often  stained,  torn, 
or  removed  in  the  repair  process.  Numerous  paper  copies 
also  use  an  incredible  amount  of  precious  space,  and  this 
issue  has  prompted  new  research  such  as  the  paperless  ship 
initiative  to  reduce  the  amount  of  paper  on  U.S.  naval 
ships.  Even  with  many  duplicate  copies  present  aboard 
ship,  a  needed  technical  manual  often  cannot  be  found  in 
its  assigned  location. 

3.  Technical  libraries  are  notoriously  difficult  to  keep 
up  to  date,  properly  sorted,  centrally  located  or 
distributed  as  required.  Technical  librarians  are  often 
junior  sailors,  or  even  worse,  sailors  who  can  not  do 
anything  else.  They  are  usually  not  formally  trained,  and 
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often  are  held  accountable  for  documentation  to  equipment 
that  they  have  little  interest  in  themselves,. 

4 .  There  is  often  an  inadequate  record  of  maintenance, 
actions  performed  on  specific  equipment .  An  automated 
system  could  conceivably  keep  an  effective  audit  trail  of 
the  actions  taken  and  how  often.  Manual  notebooks  and' 
equipment  material  histories  currently  in  use  are  often 
out  of  date,  illegible,  or  misplaced, 

5 .  Many  sailors  are  intimidated  by  large  unwieldy 
technical  manuals  that  can  be  difficult  to  navigate 
through.  The  organization  and  logical  flow  of  the 
troubleshooting  sections  of  many  technical  manuals  are  not 
always  intuitively  obvious,  and  can  further  discourage  the 
average  sailor. 


A  computerized  expert  database  system  developed  from  a 
commercially  available  expert  system  shell  and  database 
management  system  could  greatly  mitigate  many  aspects  of  the 
aforementioned  problems.  By  coupling  an  expert  system  to  a 
database,  the  knowledge  base  could  be  greatly  expanded  while 
still  maintaining  the  flexibility  of  a  database  system.  This 
would  allow  the  many  changes  due  to  frequent  technical  updates 
to  be  incorporated  separately  in  the  database  while 
maintaining  the  integrity  of  the  expert  system  program.  This 
thesis  will  develop  a  prototype  of  such  a  system  for  a 
specific  equipment  to  prove  the  viability  of  integrating 
expert  system  and  database  management  technology  in  performing 
shipboard  maintenance. 


B.  OBJECTIVES 

The  objectives  of  this  thesis  are  to  demonstrate  the  value 
o^  expert  system  technology  in  the  performance  of  shipboard 
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maintenance,  and  to  combine  an  expert  system  with  a  database 
management  system  to  produce  a  working  expert  database  system. 

C.  RESEARCH  QUESTIONS 

This  study  seeks  to  answer  the  following  primary  and 
secondary  research  questions: 

Can  an  expert  database  system  assist  maintenance  personnel 
in  the  performance  of  shipboard  corrective  maintenance? 
it  will  also  address  the  four  following  questions: 

1.  Can  a  commercially  available  expert  system  shell 
(VP-EXPERT)  be  used  to  develop  a  working  prototype? 

2.  Can  equipment  technical  documentation  be  stored  in  a 
commercially  available  database  management  system  (DBASE 
IV)  and  effectively  called  upon  by  an  expert  system? 

3.  What  are  the  benefits  of  using  an  expert  system  for 
troubleshooting  shipboard  machinery? 

4.  What  type  and  degree  of  coupling  will  be  required 
between  the  expert  system  and  the  database  management 
system? 

D .  SCOPE 

Shore  Intermediate  Maintenance  Activity  (SIMA) ,  San  Diego, 
provided  the  technical  documentation  for  a  NAXI  100-2  Low 
Pressure  Air  Compressor  to  form  the  prototype's  knowledge 
base.  The  system  has  been  designed  to  guide  the  user  through 
the  basic  troubleshooting  process  by  first  identifying  the 
symptoms,  possible  causes,  and  finally,  what  solutions  are 
available.  The  system  interfaces  with  a  database  management 
system  to  call  up  selected  procedures  to  be  used  for  problem 
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solutions;  An  initial  prototype  expert  system  was  vdeyeloped 
and  taken  to  SIMA  fpr  testing  by  the  appropriate  resident 
experts .  The  expert  system  was  then  coupled  to  a  database  to 
form  the  final  prototype  to  determine  if  this  form  of 
shipboard  maintenance  is  a  feasible  application  of  an  expert 
database  system. 

E .  METHODOLOGY 

A  prototyping  approach  was  followed  in  the  design  and 
development  of  this  syscem.  Knowledge  was  acquired  for  the 
system  principally  from  the  technical  manual'  s  troubleshooting 
guide  and  phone  interviews  with  equipment  experts  from  SIMA, 
San  Diego.  This  knowledge  was  used  to  develop  "if-then”  rules 
for  the  expert  system  shell.  The  expert  system  interacts  with 
the  user  with  a  set  of  questions,  and  the  replies  trigger  the 
rules  to  provide  expertise.  Separate  procedures  to  be  used  to 
complete  the  solution  are  kept  in  a  separate  database  and 
called  on  demand. 


F .  ORGANIZATION 

The  following  is  a  summary  of  the  chapters : 


I.  Introduction  -  The  background,  objectives,  research 
questions,  scope,  methodology,  and  organization  of  the 
research  is  presented. 

II.  Current  Environment  -  The  current  maintenance 
practices  in  use  in  the  fleet,  and  the  current  expert 
system  and  database  technology  available  is  reviewed  in 
this  chapter. 


4 


III.  Analysis  and  Design  of  the  Expert  System  Component  - 
This  chapter  includes  the  decision  domain,  design  and 
implementation  of  the  expert  system  component. 

IV.  Analysis  and  Design  of  the  Database  System  Component 
This  chapter  includes  the  definition,  requirements, 
design  and  implementation  of  the  database  system 
component . 

V.  Conclusions  and  Lessons  Learned  -  The  first  and  second 
prototype  reviews,  the  lessons  learned  using  the  VP-EXPERT 
shell  and  DBASE  IV  database  system,  and  the  research 
conclusions  are  presented. 

Appendices  -  These  sections  include  the  expert  system 
decision  tree,  sample  consultation,  the  database  object 
and  domain  definitions,  relationships,  update  and  control 
mechanisms,  dataflow  diagrams,  and  menus. 


5 


II.  CURRENT  ENVIRONMENT 


A.  CURRENT  TROUBLESHOOTS.  G  METHODS 

The  current  method  for  troubleshooting  main  propulsion  and 
auxiliary  machinery  in  U.S.  Naval  ships  is  an  entirely  manual 
process  with  the  exception  of  the  preparation  of  requisitions 
to  the  supply  department  for  parts.  A  problem  will  usually  be 
initially  detected  by  a  watchstander  who  is  qualified  to 
operate  the  equipment,  but  may  not  be  qualified  to  perform  any 
scheduled  or  corrective  maintenance.  His  normal  duties  include 
the  monitoring  of  equipment  operating  parameters  and  basic 
house  cleaning  within  his  assigned  space.  He  is  usually 
qualified  to  start,  stop  and  monitor  his  assigned  equipment 
only  within  the  strict  guidance  provided  by  the  Engineering 
Operating  and  Sequencing  System  (EOSS) .  EOSS  is  further 
divided  into  Engineering  Operating  Procedures  (EOP)  which  are 
used  for  starting,  stopping,  and  monitoring  of  normal 
operation,  and  Engineering  Operating  Casualty  Control  (EOCC) 
which  is  used  to  provide  emergency  response  to  equipment 
casualties . 

The  Naval  Sea  Systems  Command  (NAVSEA)  provides  all 
guidance  for  the  normal  operation,  casualty  control, 
preventive  and  corrective  maintenance  of  shipboard  engineering 
machinery  .  Technical  manuals  are  provided  to  each  ship  for  all 
assigned  equipment.  The  paper  and  microfiche  copies  are  kept 
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in  a  space  designated  as  the  ship's  technical  library,  and  a 
sailor  is  given  the  job  as  technical  librarian.  On  large  ships 
this  may  be  a  primary  duty,  but  on  most  ships  it  is  a 
collateral  duty. 

Technical  manuals  typically  contain  general  descriptions 
of  component  systems,  safety  precautions,  operating 
procedures,  scheduled  preventive  maintenance,  corrective 
maintenance  (troubleshooting) ,  system  diagrams,  parts  list, 
and  installation  procedures.  The  technical  manual  forms  the 
basis  for  EOSS  and  the  Preventive  Maintenance  System  (PMS) , 
which  are  much  more  specific  in  their  detail.  Because  they  are 
more  specific  and  detailed,  EOSS  and  PMS  take  precedence  over 
the  technical  manual,  but  corrective  maintenance  is  usually 
performed  using  the  technical  manual  alone.  In  some  cases  a 
PMS  procedure  may  be  used  to  correct  a  specific  problem  (i.e. 
replacing  a  clogged  filter) .  Changes  to  procedures  which 
require  immediate  attention  may  be  sent  via  a  radio  message  or 
class  advisory,  otherwise  routine  technical  updates  and 
changes  are  sent  via  normal  naval  correspondence. 

When  a  watchstander  detects  a  problem  and  takes  immediate 
action  in  accordance  with  EOCC,  the  equipment  is  secured  and 
a  sailor  qualified  to  perform  the  required  troubleshooting  is 
called  to  the  space.  If  the  problem's  cause  is  not  immediately 
obvious,  the  technical  manual  is  consulted.  Most  technical 
manuals  contain  a  troubleshooting  guide  which  can  be  followed 
to  narrow  the  problem  down  to  its  specific  cause.  This  cause 
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is  matched  with  a  specific  solution  to  the  problem,  usually  a 
reference  to  the  page  and  paragraph  of  a  corrective 
maintenance  procedure.  The  corrective  maintenance  procedure 
outlines  the  specific  steps  to  be  followed,  the  tools  and 
parts  required,  and  any  safety  precautions  and  considerations. 

Problems  arise  as  soon  as  the  cause  of  equipment  casualty 
is  not  readily  apparent  and  the  technical  manual  must  be 
consult. ad.  First  a  copy  of  the  technical  manual  must  be  found. 
If  a  copy  is  kept  in  the  engineering  space,  the  chances  are 
that  it  is  in  poor  condition.  Space  copies  are  typically 
stained  with  various  greases  and  oils  and  plagued  by  many  torn 
and  missing  pages,  and  retrieved  loose  pages  are  frequently 
shoved  back  in  the  manual  at  random  locations.  These  copies 
are  also  usually  out  of  date  and  missing  the  latest  revisions 
and  changes.  If  a  copy  of  the  technical  manual  must  be  checked 
out  of  the  technical  library,  it  may  be  in  better  condition, 
but  first  it  must  be  found.  The  manuals  are  kept  in  shelves  in 
order  of  their  assigned  NAVSEA  TECHNICAL  MANUAL  number,  so 
first  the  index  must  be  found,  the  number  looked  up,  and  the 
manual  found  (provided  the  last  user  replaced  it  properly) . 
Since  it  is  usually  a  collateral  duty,  the  technical  librarian 
must  fit  the  proper  care  of  the  library  in  with  his  own 
primary  duties  and  watchstanding.  His  duties  as  the  technical 
librarian  include  making  sure  manuals  are  properly  checked  out 
and  returned,  ensuring  they  are  kept  in  the  proper  order  on 
the  shelf,  and  entering  the  appropriate  revisions  and  changes 
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as  they  arrive.  Successful  ships  know  the  importance  of  this 
job,  but  on  many  ships  there  may  be  a  tendency  to  relegate 
this  task  to  a  more  junior  sailor  or  one  that  is  less  skillful 
in  his  primary  maintenance  duties.  Consequently,  the  quality 
of  the  technical  library  often  suffers. due  to  inattention  or 
neglect.  Even  if  the  technical  librarian  is  exceptionally 
competent  and  diligent,  he  cannot  be  present  24  hours  a  day, 
and  must  rely  on  proper  procedures  being  followed  in  his 
absence.  In  the  rush  of  a  critical  repair,  proper  procedures 
in  the  technical  library  are  usually  given  an  expectedly  low 
priority . 

Once  found,  the  technical  manual  must  be  searched  for  the 
troubleshooting  guide.  Troubleshooting  guides  do  not  follow  a 
standard  format  and  may  vary  greatly  in  logic  and  clarity 
between  different  technical  manuals.  Some  are  in  paragraph 
form,  while  others  are  tabular  or  follow  a  flowchart  format. 
Many  sailors  are  immediately  inLimidated  by  the  heft  and 
complexity  of  many  technical  manuals,  especially  those  for  the 
larger  auxiliary  and  main  propulsion  pieces  of  equipment. 
Reading  competency  may  also  vary  greatly  between  sailors, 
which  can  increase  anxiety  when  faced  with  multiple  volumes  of 
technical  jargon.  The  result  is  that  many  sailors  will  perform 
troubleshooting  in  a  haphazard  "hit  or  miss"  fashion  with  only 
a  cursory  glance  at  the  technical  manual.  They  often  rely 
heavily  on  their  own  experience  and  expertise  which  can  vary 
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greatly  between  individuals,  and  this  often  results  in  an 
inconsistent  or  ineffective  troubleshooting  effort. 

An  expert  system  for  engineering  maintenance  could 
alleviate  many  of  the  problems  that  exist  in  the  current 
environment.  The  central  location  of  a  computer  would  solve 
many  of  the  problems  caused  by  duplicate  copies  in  poor 
condition.  There  would  be  no  lost  time  searching  the  spaces  or 
the  technical  library  shelves  for  the  proper  technical  manual. 
The  troubleshooting  guide  could  be  logically  and  clearly 
presented  by  a  series  of  questions  which  would  guide  the  user 
to  the  specific  problem  and  solution.  This  would  avoid  the 
intimidation  and  endless  page  turning  morass  of  the  large 
manuals  by  focusing  the  user's  attention  strictly  to  the 
question  at  hand.  Since  the  expert  system  is  providing  the 
bulk  of  the  expertise,  the  system  could  accommodate  a  wide 
range  of  experience  and  technical  competence.  An  accompanying 
database  called  by  the  expert  system  could  logically  organize 
the  corrective  procedures  called  for  display  and  printing. 

Corrective  maintenance,  or  troubleshooting,  as  a  problem 
domain  lends  itself  exceptionally  well  to  expert  system 
development.  According  to  Leibowitz  [Ref.  1],  a  task  candidate 
for  an  expert  system  must  have  the  following  characteristics: 

1.  The  Task  Should  Be  Well-bounded. 

The  task  should  encompass  a  relatively  specific  amount 
of  knowledge,  consisting  of  facts  within  a  narrow  scope. 
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Machinery  troubleshooting  is  a  perfect  example  of  a  well- 
bounded  and  specific  task. 

2 .  The  Task  Involves  Symbolic  Versus  Numerical 

Processing. 

This  refers  to  the  execution  of  symbols  or  strings  of 
characters.  Significant  numerical  calculations  could  be  better 
performed  with  conventional  programming  languages. 
Troubleshooting  requires  little  or  no  numerical  calculations. 

3.  The  Task  Can  Be  Solved  Relatively  Quickly. 

If  a  task  requires  more  than  a  few  weeks  to  solve  than 
an  expert  system  would  not  be  appropriate.  Most  equipment  can 
be  quickly  analyzed,  and  the  troubleshooting  process  itself  is 
not  time  consuming  when  considered  separately  from  the 
physical  process  of  component  disassembly. 

4.  The  Task  Is  Performed  Frequently. 

The  usefulness  of  an  expert  system  is  maximized  when 
the  expert  system  is  used  to  solve  a  task  repeatedly. 
Shipboard  equipment  is  run  constantly  under  harsh 
environmental  conditions,  and  breakdowns  are  frequent.  An 
expert  system  to  perform  these  tasks  would  get  plenty  of  use 
to  justify  its  development. 

5 .  There  Is  A  Significant  Difference  Between  the  Best  and 

Worst  Performers .. 

A  task  is  more  suitable  for  an  expert  system  when 
there  is  a  large  discrepancy  between  the  best  and  worst 
performers  of  the  task.  As  previously  discussed,  this  is 


certainly  the  case  for  most  sailors  performing  troubleshooting 
in  the  fleet. 

6.  Test  Data  Is  Available. 

This  is  not  a  firm  requirement,  but  can  be  helpful. 
There  are  plenty  of  successful  troubleshooting  cases  to  serve 
as  comparisons  for  determination  of  expert  system  performance . 

7 .  There  Should  Be  Consensus  on  How  the  Task  Can  Be 

Solved . 

The  experts  must  agree  on  how  to  solve  the  task. 
Again,  troubleshooting  procedures  are  clear  and  well-bounded, 
and  there  is  little  room  for  variation  from  prescribed 
solutions . 

8 .  Experts  Exist  and  Can  Participate . 

There  are  plenty  of  sailors  available  to  tap  for 
expertise,  and  to  evaluate  a  system.  SIMA  San  Diego  is  a 
particularly  good  source  of  qualified  technicians  with  current 
and  recent  shipboard  experience  in  troubleshooting. 

B .  EXPERT  SYSTEMS 

An  expert  system  is  a  knowledge-based  computer  system  that 
attempts  to  replicate  what  human  experts  normally  do.  Human 
experts  may  make  decisions,  recommendations,  or  actually 
perform  tasks.  They  may  also  train  others  to  do  these  same 
tasks  or  make  the  same  decisions.  Expert  systems  are  designed 
to  perform  these  functions  also.  [Ref.  2] 
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For  this  study  the  term  expert  refers  to  a  troubleshooting 
repair  person  who  is  particularly  adept  at  his  job.  The  expert 
system  enables  a  user  with  a  problem  (i.e.,  how  to  find  the 
cause  of  machinery  failure  and  a  way  to  repair  it)  to  use  a 
computer  system  as  they  would  an  expert  advisor  to  guide  them 
through  diagnosing  what  might  be  causing  the  problem  and  how 
to  solve  it.  This  is  called  a  consultation. 

Like  a  human  expert,  the  system  can  extract  additional 
information  or  data  from  the  user  with  questions  related  to 
the  problem.  During  a  consultation  the  system  can  also  answer 
questions  about  why  certain  information  is  needed  and  the 
reasoning  steps  gone  through  to  reach  a  conclusion,  and  it  can 
make  recommendations  for  solving  the  problem  at  the  end  of  the 
consultation.  [Ref.  3] 

The  distinguishing  characteristics  of  expert  systems  are 
that  they: 

1.  Contain  symbolic  programming  and  reasoning 
capabilities . 

2.  Contain  a  knowledge  base  about  a  specific  decision 
domain  distinct  from  the  inferencing  mechanism. 

3.  Contain  an  inference  engine  distinct  from  the 
knowledge  base. 

4.  Can  handle  unknown,  uncertain,  or  conflicting  data. 

5.  Allow  a  programmer  or  user  to  modify  segments  of  the 
program  easily. 

6.  Have  a  facility  to  explain  their  advice  or  reasoning 
process . 


7.  Use  if-then  rules  (heuristics)  extensively,  but  not 
necessarily  exclusively.  [Ref.  3] 

Expert  systems  can  be  created  for  a  computer  using 
programming  languages,  expert  system  shells,  or  system 
development  tools  which  fall  between  programming  languages  and 
shells.  Programming  languages  provide  the  most  flexibility, 
but  they  are  more  difficult  to  use  because  the  system 
developer  is  required  to  design  from  scratch  both  the 
knowledge  base  and  the  inference  engine  to  access  it.  Using  a 
programming  language  is  therefore  more  expensive  and  time- 
consuming.  An  expert  system  shell  can  be  easier  and  quicker  to 
use  than  programming  languages  or  development  tools.  Since  the 
inference  engine  is  preprogrammed  in  an  expert  system  shell, 
a  systems  developer's  main  work  is  to  create  the  knowledge 
base.  Microcomputer  versions  of  expert  system  shells,  such  as 
VP  Expert,  are  especially  useful  for  developing  prototype 
systems  such  as  will  be  developed  in  this  study.  Expert  system 
shells  are  easily  affordable  and  readily  available  on  the  open 
market.  Expert  systems  developed  using  a  shell  are  also  easier 
to  expand,  update  and  maintain  [Ref.  3]  .  In  the  case  of  VP 
Expert,  the  expert  system  shell  selected  for  this  study, 
technical  assistance  is  available  from  the  manufacturer  over 
the  phone  [Ref.  4],  A  system  for  shipboard  maintenance  could 
easily  be  developed  and  maintained  by  personnel  with  limited 
computer  background  or  expertise. 
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C.  DATABASE  MANAGEMENT  SYSTEMS 


A  database  is  a  self-describing  collection  of  integrated 
records.  It  is  self-describing  in  that  it  contains,  in 
addition  to  application  data,  a  description  of  its  own 
structure  called  a  data  dictionary.  In. a  database  system,  all 
application  data  is  stored  in  the  database.  [Ref.  5] 

A  database  is  more  than  a  collection  of  files.  It  includes 
the  files,  a  data  dictionary,  and  a  description  of  the 
relationships  among  the  records  in  the  files.  These 

relationships  are  stored  and  recalled  during  database 
processing  and  are  represented  by  additional  system  data  known 
as  overhead  data.  Overhead  data  includes  linked  lists, 
indexes,  and  similar  data.  It  is  in  this  manner  that  a 
database  can  be  a  collection  of  integrated  records.  [Ref.  5] 
The  advantages  of  using  a  computerized  database  system  in 
the  shipboard  environment  are  obvious  when  considering  the 
current  filing  systems  and  technical  libraries  in  use 
throughout  the  fleet.  Databases  can  store  large  amounts  of 
operational  data  and  can  be  queried  on  an  ad  hoc  basis,  which 
makes  them  the  ideal  foundation  for  decision  support  systems. 
The  data  stored  in  a  database  can  be  readily  accessed  and 
processed,  which  allows  users  to  get  answers  much  faster.  With 
the  addition  of  a  database  management  system  (DBMS)  the 
utility  of  the  database  is  even  greater. 

The  DBMS  is  a  program  (or  group  of  programs)  that  allows 
stored  data  to  be  integrated,  reduces  data  duplication, 
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ensures  data  integrity,  eliminates  program  dependency  on  file 
formats,  and  allows  even  complicated  objects  to  be  easily 
understood,  represented,  and  retrieved.  In  short,  a  DBMS  is 
the  program  which  processes  the  database.  [Ref.  5] 

A  database  system  consists  of  five  major  components: 
hardware,  DBMS  software  and  application  programs,  the  database 
itself,  procedures,  and  people.  Database  systems  are  often 
classified  by  the  number  of  users  and  the  number  of 
applications  they  support.  [Ref.  5] 

In  a  single-user  database  system,  only  one  user  at  a  time 
processes  the  database.  In  a  multi-user  database  system,  the 
database  is  processed  by  many  users  concurrently.  Multi-user 
systems  require  more  hardware  and  special  precautions  to 
prevent  two  users  using  the  system  concurrently  from 
interfering  with  each  other  [Ref.  5]  .  Database  systems  can 
also  support  one  or  many  applications .  An  application  is 
simply  a  system  that  processes  a  portion  of  the  database  in 
order  to  meet  the  information  need  cf  a  distinct  functional 
area  of  an  organization  [Ref.  6] . 

For  this  study,  a  single  user,  multi-application  database 
system  will  support  the  requirements  of  an  engineering 
maintenance  database  system.  There  are  many  low  cost,  readily 
available  commercial  products  to  fill  this  requirement,  and  a 
microcomputer,  as  commonly  found  on  most  ships,  will  provide 
the  adequate  hardware. 
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D.  EXPERT  DATABASE  SYSTEMS 


While  a  simple  computer-based  database  system  would 
greatly  assist  in  providing  the  information  needs  of  a  ship, 
in  particular  in  the  area  of  engineering  maintenance,  such  a 
system  joined  or  coupled  to  an  expert  system  presents  an  even 
greater  range  of  possibilities.  What  makes  the  bridge  between 
database  management  and  an  expert  system  possible  is  the  fact 
that  databases  and  expert  systems'  knowledge  bases  are  both 
first  and  foremost  inf ormat ion-bearing  systems .  Although  often 
considered  technically  distinct  and  separate,  their  deeper, 
more  fundamental  similarities  suggest  a  natural  union. 

[Ref.  7] 

When  moving  up  from  a  simple  database  to  an  expert 
database  one  should  view  the  database  as  an  extension  of  the 
knowledge  base.  The  advantage  of  coupling  an  expert  system  to 
a  database  is  that  a  large  amount  of  information  can  be 
organized  and  accessed  separately  while  the  knowledge  base 
remains  intact.  Additions,  modifications,  and  deletions  can  be 
easily  performed  through  a  menu-driven  format  of  the  database 
management  system  without  affecting  the  integrity  or  logic  of 
the  expert  system.  While  most  database  systems  are  easily 
understood  and  learned,  changes  to  the  expert,  system' s 
knowledge  base  require  much  more  training,  and  the  user  must 
have  an  intimate  knowledge  of  the  logic  involved.  It  is  far 
more  efficient  to  store  large  amounts  of  varying  information 
in  a  database,  and  design  the  knowledge  base  to  contain  a 


single  set  of  invariant  rules.  Therefore,  when  a  database  is 
used  in  this  fashion,  it  becomes  an  information  base,  and  can 
be  considered  as  a  part  of  the  overall  knowledge  base.  To 
distinguish  the  rules  of  the  original  knowledge  base  from  the 
information  base,  they  are  referred  to  as  the  rule  base 
[Ref.  4].  Figure  1  provides  an  illustration  of  the  concept  of 
the  expert  database  system. 


Fignre  1..  The  Expert  Database  System. 
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A  simple  expert  database  system  consisting  of  a 
commercially  available  expert  system  shell  and  a  compatible 
database  management  system  can  provide  an  ideal  system  for 
assisting  in  the  troubleshooting  of  shipboard  engineering 
equipment.  The  trouble-  shooting  guide  can  be  extracted  from 
the  technical  manual  to  form  the  basis  for  the  knowledge  of 
the  rule  base.  The  logic  of  most  troubleshooting  guides  lends 
itself  well  to  the  rapid  translation  into  a  series  of  if-then 
rules.  Questions  to  the  user  will  be  answered,  compared  to  the 
rule  base,  and  a  cause  and  solution  to  the  problem  given.  A 
separate  database  can  then  be  accessed  by  the  expert  system  to 
provide  the  detailed  procedures  required  to  correct  the 
problem.  Since  these  procedures  are  the  portions  of  the 
technical  manual  that  are  most  likely  to  be  changed  by 
periodic  technical  updates  from  NAVSEA,  their  retention  in  a 
database  facilitates  ease  of  access  and  modification  if 
required,  without  influencing  the  basic  logic  of  the  rule 
base . 

VP-EXPERT  has  been  selected  as  the  expert  system  shell  for 
this  study.  It  has  a  relatively  low  cost,  is  widely  available 
and  used,  is  easily  installed  on  microcomputers,  has  good 
technical  support,  and  has  facilities  for  coupling  with 
database  files. 

DBASE  IV  will  be  used  for  the  database  management  system. 
It  is  also  readily  available  at  a  low  cost,  easily  installed, 
has  good  technical  support,  and  is  compatible  with  VP-EXPERT. 


Together  these  two  systems  will  be  joined  to  form  a  prototype 
Engineering  Maintenance  Expert  Database  System. 
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III.  ANALYSIS  AND  DESIGN  OF  THE  EXPERT  SYSTEM  COMPONENT 


A.  THE  OVERALL  SITUATION  STUDIED:  THE  EXPERT'S  DOMAIN 

1 .  Decision  Selection 

The  general  area  under  study  is  the  corrective 
maintenance  or  "troubleshooting"  of  a  piece  of  machinery  that 
is  not  operating  according  to  prescribed  specifications.  For 
this  study  the  particular  machinery  involved  pertains  to  main 
propulsion  or  auxiliary  shipboard  equipment.  These  systems 
are  largely  electro-mechanical  in  nature  with  associated 
electrical  and  electronic  control  and  monitoring  systems. 

Troubleshooting  was  selected  as  the  subject  for  this 
expert  system  development  for  several  reasons: 

1.  Troubleshooting  is  a  vital  and  mission  essential 
process  in  U.S.  Naval  ships,  and  it  is  performed  by  only 
a  few  selected  experts  in  a  particular  ship.  This 
expertise  can  be  variable  and  scarce. 

2.  Troubleshooting  decisions  involve  informed  judgement 
applied  in  a  deductive  logic  well-suited  to  expert  system 
development . 

3.  Troubleshooting  decisions  are  made  in  a  reasonable 
amount  of  time  and  are  clear,  structured  and  well-defined. 

2 .  The  Decision  Making  Process 

Troubleshooting  is  the  process  of  analyzing  the 
symptoms  of  a  given  problem,  determining  the  cause,  and 
applying  a  solution  to  correct  the  problem.  In  this  process  a 
qualified  technician,  the  expert  for  the  purpose  of  this 
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study,  initially  surveys  the  problem,  checks  a  few  obvious 
possible  causes,  and  then  refers  to  a  checklist  or 
troubleshooting  guide  if  the  problem  was  not  immediately 
corrected.  Troubleshooting  guides  as  provided  by  most 
equipment  technical  manuals  are  usually  arranged  with  a 
flowchart  or  checklist  of  possible  causes  under  each  of  a 
number  of  common  problems.  The  expert  then  checks  each 
possible  cause  on  the  list  to  determine  what  is  causing  the 
problem.  [Ref.  8] 

The  process  of  checking  a  possible  cause  requires  its 
own  expertise  as  the  information  given  in  the  guide  is  usually 
only  a  question  as  to  whether  or  not  a  given  condition  exists. 
The  technician  must  possess  a  certain  expertise  to  make  many 
of  these  determinations.  For  example,  a  troubleshooting  guide 
may  ask  if  a  certain  electrical  switch  is  defective,  and  it  is 
up  to  the  technician  to  make  that  determination.  The  prototype 
developed  for  this  study  will  be  restricted  to  the  expertise 
provided  by  the  technical  manual,  but  further  iterations  could 
be  expanded  to  include  the  full  expertise  required  of  the 
troubleshooting  technician. 

B.  DOCUMENTING  THE  PROTOTYPE 
1 .  System  Proposal 

The  expert  system  portion  of  the  Engineering 
Maintenance  Expert  Database  System  is  constructed  from  a 
technical  manual  troubleshooting  guide  using  the  VP-EXPERT 
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expert  system  shell.  For  the  purpose  of  this  study,  a 
prototype  system  was  developed  to  troubleshoot  the  NAXI  100-2 
Low  Pressure  Air  Compressor.  With  minimal  training  of  a 
designated  technician,  similar  systems  could  be  developed  and 
maintained  using  the  technical  manuals  of  each  piece  of 
engineering  equipment  found  on  a  particular  class  of  ship. 
Most  technical  manuals  possess  a  troubleshooting  guide  which 
is  logically  laid  out  in  such  a  fashion  as  to  allow  the  rapid 
translation  into  a  set  of  if-then  rules  of  the  expert  system 
shell.  At  the  low  initial  purchase  cost  of  the  system  shell, 
virtually  an  unlimited  number  of  equipments  could  be 
supported.  Such  a  system  would  free  shipboard  technicians  from 
reliance  on  numerous  unwieldy  paper  copies  of  technical 
manuals  while  presenting  a  clear  and  concise  approach  to 
troubleshooting  each  piece  of  equipment. 

While  users  of  the  system  could  be  any  technician 
qualified  to  work  on  the  particular  piece  of  equipment  for 
which  he  is  troubleshooting,  system  development  and 
maintenance  should  be  restricted  to  one  or  two  trained 
individuals  to  maintain  the  knowledge  base  integrity. 

2..  Prototype  System  Description 

a.  System  Overview  and  Objective 

The  prototype  system  will  ask  the  user  a  number  of 
questions  about  the  operating  conditions  of  the  equipment  to 
determine  the  symptoms  and  possible  causes  of  a  given  problem. 
When  a  problem  has  been  isolated,  the  user  will  be  presented 


with  a  solution  to  the  problem.  The  solution  is  based  upon  the 
backward  chaining  inferencing  through  the  rule  base  to  arrive 
at  a  value . 

b.  Recommendations  to  be  Made  by  the  System 

For  prototyping  purposes,  the  system  is  limited  to 
the  problems,  causes  and  solutions  given  in  the 
troubleshooting  guide  of  the  technical  manual  [Ref.  8]  .  A 
given  problem  will  have  several  possible  causes.  Questions  to 
the  user  will  be  used  to  isolate  a  cause  and  present  a  simple 
solution.  When  required,  more  detailed  solution  procedures 
will  be  referenced  by  the  paragraph  in  the  technical  manual, 
and  the  actual  procedure  steps  will  be  called  and  displayed 
from  an  accompanying  database. 

3 .  Prototype  Knowledge  Base  Design 

The  nature  of  the  troubleshooting  problem  dictates 
that  there  can  be  many  possible  causes  to  many  problems,  and 
in  turn  many  possible  solutions.  Therefore,  the  knowledge  does 
not  lend  itself  well  to  segmentation  or  a  standard  dependency 
diagram. 

Appendix  A,  Figures  A1  and  A2  depict  a  graphic 
representation  of  the  decision  tree  used  to  form  the  rule 
base.  The  first  question  to  the  user  determines  if  the 
equipment  will  start  when  turned  on.  A  negative  response  forms 
the  first  premise  for  rules  0  to  11,  which  all  lead  to  causes 
why  the  compressor  may  not  start  and  provide  a  solution  to  the 
problem.  An  affirmative  response  to  the  start  question  leads 
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the  user  to  the  remaining  rules  dealing  with  a  compressor  that 
starts  and  then  shuts  down.  This  group  is  further  broken  down 
into  three  groups  for  how  long  the  compressor  runs  before 
shutting  down. 

Rules  12  to  15  deal  with  a  compressor  that  shuts  down 
after  three  to  five  seconds,  and  rules  16  to  18  are  for  a 
compressor  that  shuts  down  within  two  minutes.  The  remaining 
rules  are  for  a  compressor  that  runs  longer  than  two  minutes 
before  shutting  down,  with  the  exception  of  rules  23  to  27 
which  deal  specifically  with  high  water  in  the  separator 
holding  tank,  rules  49  to  54  deal  with  high  temperature,  rules 
61  to  68  which  deal  with  low  water,  and  rules  69  to  72  which 
deal  with  high  liquid  level  in  the  condensate  sump.  Each  of 
these  groups  are  invoked  separately  whenever  these  particular 
causes  have  been  identified  because  they  can  be  causes  of  more 
than  one  type  of  shutdown.  For  example,  a  high  water  condition 
could  cause  the  compressor  to  shut  down  in  three  to  five 
seconds  as  per  rule  13,  or  it  could  be  the  cause  of  an 
automatic  shutdown  after  the  compressor  has  run  for  longer 
than  two  minutes.  In  each  of  these  cases,  a  separate  WHILETRUE 
clause  in  the  ACTIONS  block  of  the  program  will  be  called  to 
find  the  cause  of  the  high  water,  high  temperature,  low  water, 
or  high  condensate  level. 

Referring  back  to  Appendix  A,  once  it  has  been 
determined  that  the  compressor  runs  for  longer  than  two 
minutes,  then  the  rules  are  further  grouped  as  follows:  rules 
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19  to  22  and  28  and  29  deal  with  automatic  shutdowns,  rules  30 
to  33  are  for  a  compressor  that  will  not  automatically  stop  or 
unload,  rules  34  to  37  are  for  a  compressor  that  will  not 
automatically  restart  in  the  automatic  mode,  rule  38  is 
specifically  for  a  safety  valve  lifting  prematurely,  rules  39 
to  47  are  for  low  receiver  air  pressure,  rules  55  to  60  deal 
with  high  seawater  outlet  temperature,  and  rules  73  to  81  are 
for  an  abnormal  noise  in  the  compressor. 

C .  PROTOTYPE  IMPLEMENTATION 

Appendix  B  is  provided  as  a  sample  consultation  using  the 
prototype  system,  which  has  been  given  the  name  The  LPAC 
Troubleshooter.  The  user  of  the  system  is  expected  to  be 
familiar  with  the  VP-EXPERT's  basic  operations  and  options 
available  through  the  introduction  and  control  screens. 
Chapter  1  of  the  VP-EXPERT  manual  [Ref.  4]  provides  an 
adequate  explanation  of  the  basic  commands  needed,  and  the 
prototype's  introductory  screens  also  review  how  the  user  can 
make  selections. 

Refer  to  Appendix  B  for  the  screen  displays  and  the  types 
of  questions  asked  during  an  actual  consultation  with  The  LPAC 
Troubleshooter . 
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IV.  ANALYSIS  AND  DESIGN  OF  THE  DATABASE  COMPONENT 


A.  SYSTEM  DEFINITION 

The  database  system  developed  for  this  study  is  titled  The 
Shipboard  Maintenance  Database.  It  is  intended  to  serve  as  a 
prototype  for  use  with  the  expert  system  developed  for  this 
thesis,  the  LPAC  Troubleshooter.  As  a  prototype,  this  system 
has  been  developed  to  demonstrate  the  value  of  coupling  a 
database  to  an  expert  system  to  form  an  expert  database  system 
to  assist  in  the  performance  of  corrective  maintenance  in  U.S. 
Navy  ships.  While  this  particular  database  provides  the 
necessary  basic  information  to  conduct  certain  corrective 
maintenance  tasks,  an  actual  shipboard  system  could  be  greatly 
expanded  to  include  preventive  maintenance,  safety 
precautions,  mission  impact,  and  full  supply  interface  for 
parts  support.  However,  for  the  purpose  of  this  study,  the 
system  scope  has  been  limited  to  only  those  objects  required 
to  perform  corrective  maintenance. 

Users  of  this  system  would  include  sailors  performing 
corrective  maintenance  on  U.S.  Navy  shipboard  auxiliary  and 
main  propulsion  equipment,  the  division  Leading  Petty  Officer 
responsible  for  maintaining  and  updating  the  system,  the 
division  Chief  Petty  Officer,  and  the  Division  Officer.  The 
prototype  for  this  study  will  use  the  NAXI  100-2  Low  Pressure 
Air  Compressor  as  the  equipment  example,  but  the  system  has 


been  designed  to  include  all  of  the  engineering  equipment  in 
a  destroyer-sized  ship. 

As  a  stand-alone  system  without  the  expert  system,  users 
could  access  the  database  to  obtain  basic  equipment  and  system 
characteristics,  information  on  equipment  problems,  symptoms, 
and  the  corrective  procedures  and  parts  required  to  correct  a 
problem.  All  information  used  by  the  system  will  be 
restricted  to,  and  taken  directly  from  the  equipment's 
technical  manual. 

The  purpose  of  such  a  system  would  be  to  effectively 
automate  a  ship's  technical  manual,  thereby  freeing  the 
maintenance  technician  from  cumbersome  paper  copies  and 
providing  a  centralized  access  to  technical  information.  As  a 
separate  system  from  the  expert  system,  a  database  could  be 
more  easily  updated  and  modified  than  the  expert  system's  rule 
base.  A  separate  database  also  allows  greater  access  to  the 
technical  information  for  purposes  other  than  troubleshooting. 

This  study  will  use  the  DBASE  IV  database  management 
system  for  implementation.  This  software  is  readily  available, 
relatively  easy  to  learn,  and  compatible  with  the  hardware 
currently  in  the  fleet.  The  prototype  is  considered  entirely 
feasible  in  its  current  form  as  a  shipboard  database 
application . 
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B .  USER' S  REQUIREMENTS 

The  user's  requirements  are  designed  to  meet  two  goals: 
data  requirements  and  functional  requirements. 

1 .  Data  Requirements 

Data  requirements  are  the  data  elements  stored  in  the 
database  to  support  the  applications.  This  study  will  follow 
an  object-oriented  methodology  to  fulfill  these  requirements. 

a .  Data  Objects 

An  object  is  a  named  collection  of  properties  that 
sufficiently  describes  an  entity  in  the  user's  work 
environment.  [Ref-  5] 

For  this  study,  the  objects  defined  included 
EQUIPMENT,  SYSTEM,  CORRECTIVE  PROCEDURE,  and  PROBLEM.  Appendix 
C  provides  the  specifications  and  diagrams  for  each  of  these 
objects . 

b .  Object  Descriptions 

(1)  Equipment  Object.  The  EQUIPMENT  object  is 
used  to  describe  any  piece  of  main  propulsion  or  auxiliary 
equipment  found  in  a  ship's  engineering  plant.  Its  properties 
include  a  name  (EName)  which  it  is  commonly  referred  to,  a 
specific  model  number  (modelno) ,  the  systems  it  is  a  composed 
of,  its  manufacturer  (manufact )  ,  its  technical  manual 
(Techman) ,  and  the  number  of  units  (number)  found  on  this 
particular  ship.  Appendix  C  provides  the  full  domain 
descriptions  for  each  property. 
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(2)  System  Object.  The  SYSTEM  object  describes 
each  of  the  systems  which  make  up  a  piece  of  equipment  and  as 
such  is  an  object  property  of  the  EQUIPMENT  object.  Its 
properties  include  a  common  name  (SName) ,  a  brief  description 
of  its  purpose  (SDescrigt) ,  the  equipment  it  is  found  in,  and 
any  problems  that  could  be  associated  with  the  system.  As  an 
example,  a  piece  of  equipment  such  as  the  low  pressure  air 
compressor,  consists  of  the  following  systems:  electrical, 
air,  dehydrator,  fresh  water  injection,  etc.  The  electrical 
system  could  have  a  problem  such  as  open  undervoltage  relays. 
Problem  is  a  multi-valued  (MV)  property,  in  that  a  given 
system  can  have  many  possible  problems. 

(3)  Corrective  Procedure  Object.  The  CORRECTIVE 
PROCEDURE  object  describes  a  procedure  used  to  correct  an 
equipment  problem.  It  consists  of  a  task  name,  a  brief 
description  (TDescript )  of  what  it  is  supposed  to  do,  the 
problems  it  corrects,  the  specific  steps  (TProcedure)  of  the 
procedure,  and  any  parts  required  to  perform  the  procedure. 
For  example,  the  task  "Replace  high  level  drain  switch"  is 
performed  to  correct  the  problem  of  "high  water  in  the 
separator  holding  tank". 

(4)  Problem  Object.  The  PROBLEM  object  describes 
a  problem  that  a  system  of  a  piece  of  equipment  may 
experience.  Its  properties  include  a  common  name  (PName) ,  the 
symptoms ,  the  cause  of  the  problem,  the  corrective  procedure 
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(procedure)  to  correct  the  problem,  and  the  system  that 
usually  has  the  problem. 

2 .  Functional  Requirements 

Functional  requirements  consist  of  the  applicau ions' 
update,  display,  and  control  mechanisms  used  on  the  data 
objects  to  satisfy  the  user's  information  needs.  They  are  best 
illustrated  with  data  flow  diagrams  as  per  Figures  C2  to  C 6  in 
Appendix  C. 

An  application  is  a  collection  of  menus,  reports,  forms, 
and  programs  that  addresses  the  needs  of  a  user  group. 

[Ref.  5] 

For  this  study  the  database  system  has  been  designed 
to  support  two  applications:  The  Leading  Petty  Officer 
application  and  the  Troubleshooting  application.  Appendix  C 
provides  a  summary  of  the  update,  display,  and  control 
mechanisms  for  each  application. 

a.  The  Leading  Petty  Officer  Application 

According  to  the  dataflow  diagrams  in  Appendix  C, 
Figures  C2  through  C6  ,  the  leading  petty  officer  is 
responsible  for  all  aspects  of  maintaining  The  Engineering 
Maintenance  Database.  This  means  that  this  user's  application 
must  be  able  to  create,  edit,  and  delete  instances  of  the 
EQUIPMENT,  SYSTEM,  CORRECTIVE  PROCEDURE,  and  PROBLEM  objects. 
Although  creations  and  deletions  would  be  rare,  technical 
updates  from  NAVSEA  could  require  frequent  editing  of  the 
CORRECTIVE  PROCEDURE  object. 
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(1)  Leading  Petty  Officer  Update  Mechanises.  The 
leading  petty  officer  (LPO)  creates  all  objects  using  data 
from  the  technical  manuals.  If  a  piece  of  equipment  is  new  to 
the  ship  or  it  has  not  yet  been  entered  into  the  database,  the 
leading  petty  officer  enters  all  new  instances  of  the 
EQUIPMENT,  SYSTEM,  CORRECTIVE  PROCEDURE,  and  PROBLEM  objects . 
Changes  to  the  database  in  the  form  of  technical  updates  are 
taken  from  data  provided  by  NAVSEA  technical  updates  and 
directives.  These  are  usually  changes  to  corrective  procedures 
or  parts.  Figure  C8,  in  Appendix  C,  is  an  example  of  a  form 
that  the  leading  petty  officer  would  use  to  enter  new 
EQUIPMENT,  SYSTEM,  CORRECTIVE  PROCEDURE,  and  PROBLEM  objects 
or  to  update  existing  instances. 

Figure  C9  is  a  form  to  delete  an  EQUIPMENT  object. 
This  would  be  a  rare  occurrence  and  would  result  in  removing 
the  associated  SYSTEM,  CORRECTIVE  PROCEDURE,  and  PROBLEM 
objects . 

(2)  Leading  Petty  Officer  Display  Mechanisms. 
This  application  requires  only  one  printed  report,  a  list  of 
all  equipment  and  their  technical  manuals  to  validate  the 
assigned  equipment  with  the  technical  library. 

(3)  Leading  Petty  Officer  Control  Mechanisms. 
The  main  control  required  for  this  application  is  to  ensure 
that  only  the  leading  petty  officer  or  his  designated  chief 
petty  officer  (CPO)  or  division  officer  (DIVO)  has  access  to 
add,  delete  or  edit  data.  This  can  probably  best  be  achieved 
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with  a  required  password  to  protect  the  integrity  of  the 
database . 

b.  The  Troubleshooting  Application 

The  Troubleshooting  application  will  be  used  by 
sailors  acting  as  technicians  performing  corrective 
maintenance  on  main  propulsion  or  auxiliary  machinery.  It  can 
either  be  accessed  directly  through  the  installed  DBASE  IV 
DBMS,  or  via  the  VP-EXPERT  expert  system  if  a  troubleshooting 
rule  base  has  been  established  for  the  particular  equipment. 

(1)  The  Troubleshooting  Application  Update  and 
Display  Mechanisms.  This  application  has  no  create,  edit  or 
delete  mechanisms.  Maintenance  technicians  will  access  the 
database  for  the  display  or  printing  of  information,  but  will 
not  be  able  to  alter  the  data  in  any  way.  Screen  displays  will 
be  called  to  view  the  records  of  each  object,  or  to  provide  a 
report  of  problems  by  system  or  symptoms.  These  displays  will 
also  contain  the  corrective  procedure  task  to  correct  each 
problem.  A  report  of  the  task  and  its  procedures  from  the 
CORRECTIVE  PROCEDURE  object  record  can  then  be  called  for 
display,  or  printed  and  carried  to  the  work  space.  Figure  CIO 
shows  sample  reports  of  problems,  and  Figure  Cll  shows  a 
display  of  the  corrective  procedure. 

(2)  The  Troubleshooting  Application  Control 
Mechanisms.  Access  to  the  troubleshooting  application  will  be 
restricted  by  password  to  those  petty  officers  qualified  to 
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work  on  the  equipment.  Reports  can  be  printed  and  distributed 
separately  to  other  sailors  for  training  purposes  only. 

C.  DESIGN 

The  design  blueprint  for  the  Engineerii.g  Maintenance 
Database  includes  the  logical  database  design  and  the 
application  design.  The  logical  database  design  consists  of 
the  database  schema,  application  subschemas,  and  relation 
diagrams  and  definitions,  while  the  application  design 
consists  of  the  control  mechanisms  and  the  formats  for  forms, 
reports,  and  menus. 

1 .  Logical  Databaae  Design 

a.  Database  Schema 

The  schema  or  conceptual  view  is  the  structure  of 
the  entire  database.  It  includes  the  structure  of  all  data 
types  to  be  used  by  each  application  [Ref.  5]  .  Table  C2 
provides  the  schema  of  the  Engineering  Maintenance  Database. 

b.  Application  Subschema 

The  subschema  is  that  portion  of  the  database 
processed  by  a  particular  application.  It  is  also  known  as  the 
logical  view  or  application  view  [Ref.  5]  .  Table  02  gives  the 
subschema  as  each  column  for  leading  petty  officer  and 
troubleshooting . 

c.  Relations 

The  Engineering  Maintenance  Database  is  a 
relational  database .  In  other  words,  it  is  built  upon  the 
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relational  model.  The  relational  model  is  a  concept  that  data 
is  organized  and  stored  in  two  dimensional  tables  called 
relations .  Relations  can  be  considered  files,  and  each  row  in 
the  relation  as  a  record.  The  concept  of  a  record  as  a 
collection  of  data  items  is  similar  to  a  relation  being 
considered  a  collection  of  attributes.  In  a  relation,  rows  are 
called  tuples  and  columns  are  called  attributes .  [Ref.  5] 

In  designing  the  database,  the  previously 
discussed  objects  will  be  used  to  form  relations.  By  a  process 
known  as  normalization,  the  relations  will  be  formed  by 
transforming  the  object  properties  into  attributes.  A  relation 
diagram  will  identify  the  relationships .  A  relationship  is  an 
association  between  attributes  or  rows.  Most  relationships  can 
be  better  understood  when  broken  down  to  binary  relationships . 
A  binary  relationship  is  a  relationship  involving  only  two 
record  types.  A  binary  relationship  can  be  one  to  one ,  many  to 
one,  or  many  to  many.  Each  of  these  relationships  can  be 
either  mandatory  or  optional.  [Ref.  5] 

(1)  Object  Types.  To  transform  the  objects  into 
relations,  the  structure  of  each  object  must  be  analyzed.  In 
this  system  three  objects  are  compound  objects  and  one  is  an 
association  object.  A  compound  object  contains  at  least  one 
object  property,  that  is  at  least  one  of  its  properties  is 
actually  another  object.  Consequently,  a  compound  object  is 
represented  by  at  least  two  relations,  one  for  each  object.  An 
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association  object  is  similar  to  a  compound  object,  but  it  is 
used  to  document  a  relationship  between  two  or  more  objects . 

Refer  to  the  object  diagrams  and  relation  diagrams 
in  Appendix  C.  The  EQUIPMENT  object  contains  the  SYSTEM  object 
(MV  means  there  are  many  systems) ,  the  SYSTEM  object  contains 
EQUIPMENT  and  PROBLEM  objects,  and  CORRECTIVE  PROCEDURE 
contains  the  PROBLEM  object.  Therefore,  EQUIPMENT,  SYSTEM,  and 
CORRECTIVE  PROCEDURE  are  compound  objects.  The  PROBLEM  object 
contains  both  CORRECTIVE  PROCEDURE  and  SYSTEM  objects.  Since 
it  documents  a  relationship  between  the  SYSTEM  and  CORRECTIVE 
PROCEDURE  objects,  it  is  considered  an  association  object. 
Part  V  of  Appendix  C  illustrates  each  of  the  objects 
transformed  into  relations  and  their  binary  relationship  to 
each  other. 

(2)  The  Relationships.  Each  piece  of  equipment 
must  have  many  systems  and  each  system  must  belong  to  only  one 
piece  of  equipment;  therefore,  the  relationship  is  a  mandatory 
one  to  many  between  the  EQUIPMENT  and  SYSTEM  relations.  Each 
system  can  have  many  problems  and  each  corrective  procedure 
could  correct  one  or  many  problems.  Each  problem  must  affect 
a  system,  and  must  have  a  corrective  procedure.  Therefore,  the 
relational  representation  of  PROBLEM  clearly  shows  it  to  be  an 
association  object  with  mandatory  many  to  one  relationship  to 
both  SYSTEM  and  CORRECTIVE  PROCEDURE. 
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(3)  The  Keys.  The  relations  and  relationships  of 
this  system  form  a  simple  network.  A  simple  network  is  a 
collection  of  records  and  one-to-many  relationships  among  the 
records  where  one  record  may  have  more  than  one  parent  [Ref. 
5]  .  In  this  system,  PROBLEM  has  parents  SYSTEM  and  CORRECTIVE 
PROCEDURE.  The  keys  of  each  relation  are  used  to  form  the 
relationships  of  a  network.  A  key  is  a  group  of  one  or  more 
attributes  that  uniquely  identifies  a  row.  Every  relation  has 
at  least  one  key  [Ref.  5]  .  For  the  EQUIPMENT  relation,  the 
equipment's  name,  the  attribute  EName,  is  the  key  of  the 
relation  (as  indicated  by  underlining  in  the  diagram) .  The 
one-to-many  relationship  is  effectively  formed  by  placing  the 
key  of  the  parent  in  the  child  (the  many  side) ,  and  is  then 
known  as  a  foreign  key  within  the  child.  Therefore,  the  key  of 
EQUIPMENT,  EName  is  placed  within  SYSTEM  to  form  a  mandatory 
one  to  many  relationship.  The  key  of  SYSTEM,  SName,  and 
CORRECTIVE  PROCEDURE,  Task,  are  placed  in  the  child  PROBLEM  as 
foreign  key  attributes.  Table  Cl  shows  each  of  the  attributes 
fc:.  each  relation  and  their  definitions,  including  foreign 
^eys . 

2  Application  Design 

As  previously  discussed  in  the  requirements  portion, 
the  Engineering  Maintenance  Database  System  has  two 
applications:  the  Leading  Petty  Officer  and  Troubleshooting. 
Each  application  subschema  was  summarized  in  Table  C2,  and  the 
scope  of  each  application  was  thoroughly  d’ scussed  under  the 
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database  requirements.  This  section  will  cover  the  application 
control  mechanisms,  and  the  design  of  the  menus  required. 

a.  Control  Mechanisms 

Control  mechanisms  can  be  either  menu-driven, 
command-driven,  or  a  combination  of  the  two.  The  applications 
in  this  system  will  be  menu-driven  for  the  following  reasons: 

1.  Although  slightly  slower,  menus  are  largely  self- 
explanatory  and  easier  to  use  than  commands. 

2.  Time  for  training  is  at  a  premium  aboard  ship,  and  menus 
require  less  training. 

3.  There  is  no  need  for  exceptionally  fast  data  input  or 
retrieval . 

b .  Menu  Options 

The  first  menu  is  the  Main  Menu,  and  it  will 
direct  the  user  to  the  application  desired.  Figure  C12  is  an 
example  of  the  main  menu  options.  The  next  level  will  present 
the  user  with  a  list  of  options  for  the  application  chosen. 
For  the  Leading  Petty  Officer  application,  the  next  menu  is 
shown  in  Figure  C13.  The  second  level  menu  will  provide  a  list 
of  actions  that  can  be  performed  on  the  object  data  selected 
from  the  first  level  menu.  Figure  C14  is  an  example  of  the 
second  level  menu  for  the  Leading  Petty  Officer  application 
when  equipment  is  selected.  A  similar  menu  would  appear  for 
each  of  the  other  objects  if  selected.  A  selection  from  this 
menu  would  lead  to  the  required  form  or  report  to  perform  the 
action  selected.  The  term  "browse"  refers  to  viewing  the 
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records  without  modifying  them,  and  the  "print  equipment  list" 
refers  to  the  equipment  technical  manual  list  previously 
discussed  in  the  requirements  section. 


The  menus  for  the  Troubleshooting  application  are 
similar  except  the  options  for  the  user  are  restricted  to 
browse  and  print . 

The  second  level  menu  offers  the  user  access  to 
the  CORRECTIVE  PROCEDURE  and  PROBLEM  objects  only.  Figure  C15 
is  an  example  of  the  Troubleshooting  first  level  menu.  The 
second  level  menu  offers  the  actions  available  in  this 
application.  For  corrective  procedure  data,  the  second  level 
menu  would  appear  as  Figure  Cl 6. 

For  problem  data,  the  user  would  be  presented  with 
more  options  since  there  are  additional  reports  available  for 
this  data.  Figure  C17  is  an  example  of  the  second  level  menu 
for  problem  data.  Selection  of  display  or  print  problems 
report  would  lead  to  a  third  level  menu  for  the  user  to  select 
the  problems  by  system  or  problems  by  symptom  report  as 
previously  discussed  in  requirements.  Figure  C18  is  the  third 
level  menu  for  these  options.  Selection  from  this  menu,  as 
with  previous  menus  presented,  will  require  additional  forms 
so  that  the  user  can  indicate  the  desired  record  data,  such  as 
the  problems  for  what  system  or  symptom. 
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D .  IMPLEMENTATION 


The  Engineering  Maintenance  Database  was  implemented  using 
the  commercially  available  DBASE  IV  software  package.  DBASE  IV 
was  selected  because  of  the  author's  own  familiarity  with  the 
system  and  its  widespread  use  and  availability. 

1.  Creating  the  Database  Files 

A  separate  directory  was  first  established  within 
DBASE  IV  for  inclusion  of  the  Engineering  Maintenance 
Database.  From  the  DBASE  IV  control  center  screen,  a  separate 
catalog  was  created  titled  ENGMAINT.CAT  to  hold  all  files, 
forms,  reports  and  the  two  applications. 

Database  files  were  created  for  each  of  the  objects 
defined  in  the  requirements  phase,  with  their  names  shortened 
within  the  required  eight  characters  of  a  DOS  filename.  The 
files  included:  EQUIP  (for  equipment),  SYSTEM,  CORRECT  (for 
corrective  procedure) ,  and  PROBLEM.  The  file  structures 
followed  the  domain  and  relation  definitions  of  the 
requirements  phase,  with  the  exception  of  the  CORRECTIVE 
PROCEDURE  property  TProcedure.  This  property  was  defined  to 
hold  a  series  of  procedures  within  a  memo  field  that  should  be 
followed  to  complete  a  corrective  procedure  task.  The  original 
database  file  CORRECT  was  structured  in  accordance  with  the 
object  CORRECTIVE  PROCEDURE  domain  definition  for  TProcedure. 
Sample  records  were  placed  in  the  file  and  worked  well  within 
the  confines  of  the  DBASE  IV  environment.  Problems  arose  when 
attempting  to  use  the  CORRECT. DBF  file  with  VP-EXPERT  and  the 
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LPAC  TROUBLESHOOTER  program.  Although  VP-EXPERT  can  call  most 
.dbf  files,  it  would  not  call  files  with  a  memo  field. 
Therefore,  the  TProcedure  field  of  the  CORRECT  file  had  to  be 
limited  to  the  maximum  254  characters  of  a  normal  field.  This 
created  a  severe  limitation  in  space  available  for  the 
corrective  procedure  steps . 

2 .  Creating  the  Forms  and  Reports 

Custom  forms  and  reports  were  created  quickly  using 
DBASE  IV' s  form  and  report  design  screens  and  form  generators. 
Final  products  closely  resembled  those  presented  in  the  design 
phase  with  a  few  alterations  for  practical  purposes. 

A  form  was  not  created  for  deletion  of  files  as  this 
function  is  performed  easily  using  the  installed  DBASE  IV 
menus.  A  form  format  was  chosen  for  the  problem  reports  by 
system  and  symptom  since  the  lengths  of  the  fields  made  a 
columnar  format  impractical  and  difficult  to  read. 

The  forms  for  entering  and  updating  file  records  use 
fields  with  50  character  window  widths.  If  the  field  contains 
data  of  greater  than  50  characters,  then  the  data  can  be 
entered  or  read  by  using  the  cursor  arrows  to  scroll  the  data 
through  the  window.  Directions  to  this  effect  are  in  the  field 
labels  and  as  memos  at  the  bottom  of  the  screen  when  the  field 
is  in  use. 

3 .  Creating  the  Applications 

The  Leading  Fetty  Officer  and  Troubleshooting 
applications  were  created  using  the  DBASE  IV  application 
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generator.  The  menus  created  differed  only  slightly  from  those 
presented  in  the  design  phase,  and  in  the  sample  screens  given 
in  Appendix  C,  part  VI.  Since  both  applications  are  within  the 
ENGMAINT  catalog,  there  was  no  need  for  a  main  menu  holding 
both  applications.  Either  application  can  be  selected  from  the 
DBASE  IV  control  center  within  the  ENGMAINT  catalog.  Passwords 
were  not  used  within  the  scope  of  this  implementation,  but 
each  of  the  applications  could  easily  be  protected  using  DBASE 
IV' s  file  protection  system. 

a.  The  Leading  Petty  Officer  Application 

This  application  was  created  under  the  name  LPO. 
It's  main  menu  is  in  a  horizontal  bar  format  with  each 
selection  leading  to  a  pop-up  menu.  A  separate  exit  option  was 
included  to  allow  exiting  back  to  the  DBASE  IV  control  center 
or  to  DOS.  The  pop-up  menus  closely  follow  the  second  level 
menus  presented  in  the  design  phase,  and  their  actions  use  the 
custom  forms  and  reports  already  created.  The  delete  action 
uses  the  same  form  as  the  add  and  modify  actions,  but  the  user 
is  unable  to  add  or  modify  from  this  selection.  Deletion  is 
performed  using  the  DBASE  IV  Menus  (F10) ,  selecting  Records 
and  Mark  Record  for  Deletion  or  Blank  Record.  The  browse 
action  will  display  all  records  in  DBASE  IV' s  columnar  browse 
format . 

Under  the  Equipment  Data  selection,  the  fifth 
selection  on  the  second  level  menu  will  produce  the  equipment 
technical  manual  report  presented  in  the  design  phase.  The 
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system,  corrective  procedures  and  problem  data  selection  are 
all  the  same  as  the  equipment  data,  except  there  are  no 
reports . 

b.  The  Troubleshooting  Application 

This  application  also  uses  a  horizontal  bar  menu 
for  the  main  menu,  and  menu  selections  are  the  same  as 
presented  in  the  design  phase.  The  same  exit  menu  is  also  used 
in  this  application.  Under  problem  data,  the  second  level  menu 
offers  a  browse  selection  which  allows  viewing  with  no  add, 
modify  or  delete  capability.  The  Print  a  Specific  Problem 
selection  calls  a  command  file  which  asks  the  user  for  the 
specific  problem  to  print  in  the  report  format  PROBREP.  The 
Problems  Reports  selection  activates  a  third  level  menu  which 
offers  a  problem  report  by  system  or  symptom.  Each  of  these 
selections  calls  a  separate  command  file  which  asks  the  user 
for  the  system  or  the  symptom  desired.  When  the  system  or 
symptom  is  provided,  the  reports  are  printed  in  the  SYSPROBS 
or  SYMPROBS  formats. 

The  corrective  procedures  selection  from  the  main 
menu  activates  a  second  level  menu  which  allows  the  user  to 
either  browse  the  corrective  procedure  records,  or  print  a 
desired  corrective  procedure.  The  latter  selection  calls  a 
separate  command  file  which  asks  the  user  which  corrective 
procedure  should  be  printed. 
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4 .  Data  Input 


The  actual  records  created  within  the  database  files 
were  the  minimum  required  to  illustrate  the  database  system's 
capabilities  and  potential  for  shipboard  use.  Data  on  the  low 
pressure  air  compressor  was  input  as  the  only  piece  of 
equipment,  but  the  system  could  contain  data  on  all  shipboard 
equipment .  All  corrective  procedures  that  could  be  called  by 
the  expert  system  were  included,  but  not  all  possible 
corrective  procedures  were  included.  The  EQUIPMENT,  SYSTEM, 
and  PROBLEM  files  contain  only  one  record  each  for  sample 
purposes . 

A  complete  working  system  would  require  records  for 
each  piece  of  equipment,  each  system  within  that  equipment, 
all  possible  problems,  and  each  corrective  procedure. 
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V.  CONCLUSIONS  AND  LESSONS  LEARNED 


A.  FIRST  PROTOTYPE  DEMONSTRATION 

The  first  prototype  consisted  of  the  first  version  of  the 
expert  system  without  an  associated  database.  Additionally, 
the  rules  for  several  of  the  branches  of  the  decision  tree  had 
not  been  fully  implemented/  specifically  the  high  water,  low 
water,  and  high  condensate  branches.  It  was  intended  to  simply 
demonstrate  the  concept  of  using  an  expert  system  for 
shipboard  maintenance,  and  to  allow  users  to  provide  first 
impressions  toward  its  potential  for  useful  application. 

The  initial  prototype  was  demonstrated  for  review  by  SIMA, 
San  Diego.  The  demonstration  was  conducted  on  an  actual  shop 
computer  in  the  Compressor  Maintenance  Shop,  and  the  prototype 
was  run  by  sailors  who  perform  compressor  maintenance  aboard 
ships  stationed  in  San  Diego.  In  addition,  each  of  the 
technicians  who  used  the  system  had  recently  served  on  a  U.S. 
Naval  ship,  and  were  intimately  familiar  with  the  environment 
and  current  troubleshooting  practices  in  the  fleet.  User 
experience  levels  ranged  from  the  Repair  Officer  (05)  and 
Assistant  Repair  Officer  (04)  ,  both  of  whom  are  degreed 
engineers  and  classified  as  engineering  duty  officers,  to  the 
shop  chief  petty  officer  (E7)  and  two  shop  technicians,  a 
second  class  and  third  class  petty  officers  (E5  and  E4) . 


All  users  quickly  picked  up  how  the  system  worked  in  a 
matter  of  minutes  and  agreed  that  a  system  of  this  type  would 
be  very  useful  aboard  ship.  All  agreed  that  such  a  system 
would  avoid  many  of  the  problems  previously  cited,  and  fleet 
sailors  could  be  trained  to  utilize  and  maintain  the  system. 
A  copy  of  the  system  was  left  for  an  extended  review  of  30 
days,  after  which  observations  were  recorded.  Suggested 
additions  to  the  system  revolved  mostly  around  user  interface 
issues.  Some  of  the  suggestions  given  were  as  follows: 

1.  Improve  the  user  interface  with  touch  screens,  light 
pens,  or  mouse  support. 

2.  Include  graphics  to  facilitate  user  interface,  i.e. 
provide  a  picture  or  graphic  representation  of  the 
machinery  so  the  user  can  mouse  on  to  a  part  or  component 
suspected  and  shortcut  the  majority  of  the  rule  base 
(reduces  consultation  time) . 

3.  Link  the  system  with  the  Supply  Department's  parts 
database,  i.e.  if  a  solution  requires  a  part  replacement 
then  the  user  can  check  its  inventory  status  and  fill  out 
a  requisition  through  the  system. 

4.  Increase  the  references  to  the  technical  manual,  and 
provide  all  corrective  procedures  as  called  for  in  the 
recommended  solutions. 

Each  of  these  suggestions  could  lead  to  a  greatly  enhanced 
system,  especially  in  terms  of  ease  of  user  interface. 
However,  they  were  each  determined  to  be  beyond  the  scope  of 
this  study,  with  the  exception  of  portions  of  suggestion  4. 

Suggestion  1  would  entail  the  use  of  hardware  not  yet 
available  in  the  fleet.  Although  VP-EXPERT  provides  mouse 
support,  it  is  only  available  in  the  graphics  mode  of 
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operation.  VP-EXPERT  does  provide  for  the  incorporation  of 
graphics  within  a  consultation  as  suggested  by  2,  and  follow- 
on  studies  could  possibly  explore  the  incorporation  of  this 
feature . 

Suggestion  3  would  best  be  addressed  through  the 
manipulation  and  interface  issues  of  current  shipboard 
databases  for  parts  support.  While  this  study  explores  the 
possibility  of  linking  an  expert  system  with  a  database,  as 
broad  a  system  as  suggested  is  beyond  the  scope  of  this 
prototype . 

Suggestion  4  was  partly  incorporated  in  successive 
iterations  of  the  prototype.  References  to  the  technical 
manual,  when  applicable,  were  placed  within  appropriate 
solutions  in  the  program.  The  initial  prototype  did  not  couple 
with  a  database,  but  a  skeletal  sample  database  has  been 
developed  and  linked  to  the  system  to  show  the  added 
capabilities  and  increased  effectiveness  possible  with  an 
expert  database  system.  The  development  and  implementation  of 
the  complete  database  required  for  a  working  system  was  also 
beyond  the  scope  of  this  study. 

B.  THE  SECOND  PROTOTYPE 

The  second  prototype  of  the  expert  system  included  all 
possible  branches  of  the  decision  tree.  All  references  to  the 
technical  manual  were  included,  and  additional  clauses  were 
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added  to  link  the  system  to  the  Engineering  Maintenance 
Database . 

Within  the  ACTIONS  block,  a  MENU  clause  was  added  to 
assign  the  CORRECT. dbf  file's  TASK  field  as  the  choices  for 
the  Procedure  variable.  A  separate  ASK  statement  for  Procedure 
asks  the  user  which  procedure  is  desired,  and  presents  a  list 
of  the  records  within  the  CORRECT  file,  by  task  name,  for  the 
user  to  choose  from.  The  FIND  Procedure  clause  is  used  to 
trigger  the  ASK  Procedure  statement  after  all  solutions  that 
require  a  corrective  procedure.  When  the  user  selects  the 
desired  task  from  the  list,  a  WHILETRUE  clause  in  the  ACTIONS 
block  calls  the  record  selected  from  the  CORRECT  file  and 
triggers  a  FIND  Message  clause.  This  clause  causes  the  first 
rule  (RULE  00)  to  fire  and  display  the  TProcedure  field  of  the 
record  for  the  task  selected. 

The  end  result  was  a  prototype  for  a  simple  expert 
database  system.  The  second  prototype  was  demonstrated  to  the 
same  group  of  users  from  SIMA,  San  Diego.  All  users  found  the 
system  easy  to  master,  and  quickly  picked  up  the  additional 
capability  to  call  and  view  corrective  procedures.  The  added 
potential  offered  by  such  a  system  was  quickly  recognized,  and 
all  agreed  that  such  a  system  would  be  of  value  for  performing 
shipboard  maintenance.  Their  review  and  evaluation  of  the 
system  resulted  in  the  following  additional  suggestions: 

1 .  The  window  for  the  display  of  the  corrective  procedure 

needs  to  be  larger  to  allow  a  more  detailed  and  clear 
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listing  of  the  procedure's  steps  as  contained  within  the 
technical  manual.  Use  less  abbreviations  within  the  text 
of  the  steps. 

2.  Parts  should  be  included  with  the  corrective 
procedure.  Their  description  should  include  their  stock 
number,  and  the  technical  drawing  number  they  are  found 
within. 

3.  The  ability  to  call  and  view  drawings  would  be  useful 
in  the  troubleshooting  process. 

4.  Some  of  the  task  names  presented  in  the  list  of 
procedures  were  unclear  as  to  their  purpose  or  function. 

5.  It  would  be  useful  to  be  able  to  manipulate  the 
database  management  system  from  VP-EXPERT  to  conduct 
queries . 

6.  Incorporate  the  database  within  the  new  CD-ROM 
technology . 


As  with  the  first  prototype,  each  of  the  suggestions  made 
by  the  users  could  lead  to  a  greatly  enhanced  and  more 
powerful  system.  Suggestion  1  deals  with  the  field  constraint 
of  DBASE  IV  of  254  characters  because  of  the  inability  of  VP- 
EXPERT  to  call  files  with  memo  fields.  Possibly  another  expert 
system  shell  could  perform  this  function,  but  the  current 
version  of  VP-EXPERT  is  limited  in  this  respect.  A  possible 
solution  would  be  to  continue  the  procedure's  steps  in 
additional  254  character  fields  which  could  also  be  called  by 
the  expert  system.  This  would  allow  the  procedures  to  be 
displayed  in  their  entirety  as  per  the  technical  manual. 

Suggestion  2  could  be  implemented  by  including  parts' 
stock  numbers  and  drawing  numbers  in  the  Parts  field  of  the 
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CORRECT  file.  The  expert  system  could  then  call  and  display 
this  field  in  addition  to  TProcedure. 

Suggestion  3  is  not  practical  using  VP-EXPERT.  While  the 
system  can  incorporate  graphic  images  and  diagrams  created  in 
GMODE,  its  drawing  function  is  primitive  and  only  the  simplest 
system  drawing  could  be  made.  The  detail  required  for  serious 
troubleshooting  is  found  in  the  technical  manual  or  ship' s 
drawings.  VP-EXPERT  is  unable  to  call  and  display  a  graphic 
file  such  as  .pcx.  A  simple  line  diagram  displayed  when  a  rule 
fires  might  provide  some  illustrative  value  for  the  user. 

Suggestion  4  is  a  limitation  of  VP-EXPERT.  Field  names 
displayed  as  menu  choices  are  truncated  to  20  characters. 
Therefore,  care  must  be  taken  to  ensure  a  field  that  will  be 
provided  as  a  menu  choice  is  as  descriptive  as  possible  within 
this  constraint. 

Suggestion  5  would  lead  to  a  truly  powerful  expert 
database  system.  VP-EXPERT  is  unable  to  invoke  the  database 
management  system,  and  can  only  call  a  file  as  specified  in 
the  program.  Data  can  be  read  in  and  out  of  the  file,  but  all 
of  the  queries,  menus,  and  separate  applications  available  in 
a  system  such  as  DBASE  IV  cannot  be  accessed. 

Suggestion  6  would  be  entirely  feasible  once  the  new  CD- 
ROM  technology  and  hardware  is  introduced  to  fleet  units.  CD- 
ROM  offers  a  huge  memory  capacity  in  very  little  space,  and 
opens  many  possibilities  for  the  storage  of  technical 
libraries.  Consideration  would  have  to  be  given  to  the  file 
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formats  used,  and  their  compatibility  with  an  appropriate 
expert  system  shell  such  as  VP-EXPERT.  An  expert  database 
system  using  CD-ROM  technology  could  bring  the  "paperless 
ship"  concept  to  fruition. 

The  final  opinion  of  the  users  who  reviewed  the  second 
prototype  was  that  there  are  definitely  many  useful 
possibilities  for  an  expert  database  system  in  performing 
shipboard  corrective  maintenance.  While  the  prototype  is  far 
from  complete  as  a  working  system,  it  served  its  purpose  by 
illustrating  the  potential  value  of  automating  the  knowledge 
found  in  the  technical  manual  and  human  experts. 

C .  LESSONS  LEARNED 

The  study  proved  to  be  a  success  in  demonstrating  the 
feasibility  and  potential  of  using  expert  database  technology 
to  perform  shipboard  troubleshooting.  Using  VP-EXPERT  and 
DBASE  IV  in  a  prototyping  approach  provided  some  valuable 
lessons . 

1.  Using  VP-EXPERT 

VP-EXPERT  proved  to  be  extremely  simple  to  use,  yet 
very  powerful  in  its  expert  system  capabilities.  It  was  easily 
learned  using  its  tutorial,  and  the  manual  was  relatively 
clear  and  straight-forward.  However,  some  important  points 
were  left  out  of  the  main  text,  and  only  included  in  the 
keyword  reference.  The  examples  provided  were  excellent  and 
provided  some  useful  additions  to  the  program. 
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VP-EXPERT' s  inability  to  call  database  files  with  memo 
fields  proved  to  be  a  major  source  of  frustration  when 
attempting  to  couple  the  expert  system  and  database.  This  was 
not  covered  at  all  in  the  manual,  and  only  resolved  with  a 
call  for  technical  assistance  from  the  vendor.  It  also  proved 
to  be  a  major  limitation  to  the  expert  system  and  the  database 
system  design.  It  could  have  been  resolved  by  including  the 
desired  text  in  the  knowledge  base,  or  by  calling  a  separate 
text  file  containing  the  procedure.  However,  this  would  have 
defeated  a  large  part  of  the  purpose  of  the  study  to  show  the 
value  of  coupling  to  a  database.  Inclusion  in  the  knowledge 
base  or  text  files  would  make  the  input  and  update  of  these 
procedures  a  slow  and  tedious  process,  and  simply  not 
practical  for  shipboard  use.  The  expert  system  program  should 
stand  alone  and  require  few  changes  in  the  future.  Technical 
procedures  are  subject  to  frequent  updates,  and  if  included  in 
the  knowledge  base  would  require  frequent  tinkering  with  the 
program.  A  database  management  system  is  a  more  appropriate 
tool  for  data  that  requires  frequent  updating. 

2,  Using  DBASE  IV 

DBASE  IV  proved  to  be  a  useful  and  easily  learned 
system  for  implementing  the  Engineering  Database  Management 
System.  The  form,  report,  and  menu  generators  allowed  rapid 
custom  design,  and  the  applications  generator  saved  a  great 
deal  of  programming  time.  The  design  screens  and  manual  were 
straight-forward  and  clear.  Reference  6  proved  extremely 


52 


useful  also,  and  provided  excellent  examples  for  application 
development . 

The  only  problems  arose  on  several  occasions  when  the 
system  did  some  inexplicable  actions  such  as  switching  from 
the  catalog  in  use  and  failing  to  save  several  newly  input 
records.  Each  of  these  occurred  on  several  different  sessions 
and  can  probably  be  attributed  to  "bugs"  noted  in  the  earlier 
versions  of  DBASE  IV.  Otherwise,  the  system  was  found  to  be 
ideal  for  implementing  the  simple  applications  used  in  this 
study . 

3 .  Prototyping 

Sponsorship  of  this  study  by  SIMA,  San  Diego  proved 
invaluable  in  the  prototyping  process.  Because  of  frequent 
underway  periods,  it  was  not  possible  to  use  an  actual  ship 
for  demonstrating  the  prototypes.  However,  since  SIMA's 
primary  mission  is  to  assist  ships  with  maintenance  and 
repairs,  their  personnel  were  intimately  familiar  with  all 
aspects  of  the  equipment  maintenance  and  operation,  as  well  as 
the  common  practices  found  in  the  fleet.  All  of  the  sailors  in 
the  compressor  shop  had  recently  completed  shipboard  tours, 
and  now  work  exclusively  on  ships  homeported  in  San  Diego. 
They  proved  to  be  an  invaluable  source  of  knowledge  and 
insight  into  what  would  be  useful  in  the  shipboard 
environment.  The  entire  command  was  exceptionally  computer- 
literate  at  all  levels,  even  the  compressor  shop  had  its  own 
micro-computer  tied  into  a  local  area  network  .  The  lowest 
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level  technicians  were  conversant  with  micro-computer  usage, 
and  had  definite  ideas  on  what  they  liked  and  disliked. 

Since  a  large  measure  of  the  feasibility  and 
usefulness  of  this  application  depended  on  the  reaction  of  the 
fleet  sailor  as  its  primary  user,  the  prototyping  approach  was 
the  only  appropriate  method  of  development.  The  approach  lends 
itself  well  to  expert  systems  development  as  a  whole, 
regardless  of  the  application.  The  result  was  a  system  that 
illustrated  to  the  users  the  unique  possibilities  of  using 
expert  systems  in  the  shipboard  environment. 

D.  SUMMARY 

The  study  proved  to  be  a  success  in  answering  the  primary 
question  of  whether  an  expert  database  system  is  a  feasible 
tool  for  the  performance  of  shipboard  maintenance  in  U.S.  Navy 
ships.  The  prototype  illustrated  the  potential  utility  of  such 
a  system  and  was  favorably  received  by  fleet  sailors. 
Limitations  were  found  in  the  size  of  the  field  that  VP-EXPERT 
could  call,  which  may  limit  the  potential  of  the  current 
version  of  this  particular  shell  for  this  application. 
However,  the  inclusion  of  technical  documentation  within  a 
working  database,  and  the  coupling  of  this  database  to  an 
expert  system,  showed  great  potential  utility,  regardless  of 
the  particul?-  tools  used. 
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APPENDIX  A 


THE  EXPERT  SYSTEM  DECISION  TREE 


Rll  FREE  TURN  (Y)  MOTOR  CONT 

RIO  FREE  TURN  (N)  INTERFERENCE 

R9 _ HIGH  TEMP  -  R49-54 

R8  ARPS  j  R5  THERMAL.  OVERLOAD 

R 7  AIR  PRESSURE  R6  UNDE RVOL TAG E 

- RELAYS - 1 

- MISC  PROBLEM - 1 

R2  SAFETY .SHUTDOWN  R3 LOOSE  WIRING 

R1 EMER  STOP  1 R4  BLOWN  FUSE 

RO  POWER  SWITCJ1 

R15  COMP  LEVEL  (N)  MOTOR  CONT 

R14  COND  LEVEL  (V)  - R  6 9 - 7 2 

R13  WATER  LEVEL  -  HIGH - R 23-27 

R12  WATER  LEVEL  -  LOW - R 6 1  -  6  9 

R16  RCVR  PRESS 
R17  HDPTS  (Y) _ 

RIO  liDFTG  (N)  ~  DEYHPRATOR  MALFUNCTION 
AUTOS HUT DOWN 


- £ i  g  Higi f_TEMP - R49-54 

N  Y  R2Q  DEW  POINT' 

R21  WATER  LEVEL  -  LOW - RC'1-60 

R22  WATER  LEVEL  -  HIGH - R2  3  -  2  / 

R2  0  COND  LEVEL  177 - R69-7? 

R2  9  COUP  LEVEL  (N)  MOTOR  CONT 

AUIO  UNLOAD 

- _ - R3Q  TRESS  SWrCH 

Y  V  R3l  BUTTERFLY 

R3 2  OPERATE  UNLOADED  (Y) 

R33  OPERATE  UNLOADED  (N)  MOTOR  CONI 

AUIO  SI ART 

- R34  rpjsss  SWTCH  110 

Y  V  R35  BUTTERFLY 

R 36. _ ABNORI1AL  COUP  ( Y l 

R37  ABNORMAL  COUP  (U)  MOTOR  CONI 

R3g  SAFETY  VALVE  BELOW  155 

LOW  PRESS 

- - R39  EXCESS  DEMAND 

N  Y  R40  PRESS  GAUGE  " 

R41  PRESS  SWTCH  OFEN 
R4  2  SATETY  VALVE  OPEN 
R43  COND  DRAIN 
R4 F  IAN  UAL  DRAIN. 

R4  5~LEAK'~ 

I  5IjLKATER_£RES5_j£t 

R4 l  WATER  PRESS  (N )  LEAK  IN  COMPRESSOR 


H'igure  A1  The  Lpac  Troubleshooter  Decision  Tree  (part  1) 
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R46  HIGH  TEMP 


SW  OUTLET  TEMP 

- R55  SW  CIRC  BLOCK 

H  Y  R56  SW  STRAINER 

R57  AIROP  SW  VLV 

R50  AIRBOUUD 

R5  9  INLET  TEMP  (Y) 

R60  INLET  TEMP  (H)  OVERHEATED  FART 


R73  INSURE  AJR 
R74  50V  BAD 
R75  MOTOR  ROTATION 
R76  DRIVE  MOTOR 
R77  COUPLING  DEFECTIVE 
R70  DEHYDRATOR 
R79  BACKLASH 
RO 0  TIMING  ItlCORRECT  (Y) 

ROl  TIMItlG  IUCORRECT  (IP  -  WORJtl  FART 

IITGH  WATER 

- - R23  HLDS  DEFECTIVE 

Y  R2  \  AUTO  REF  ILL  OrEtl 

P 2 5  DRAIN  BLOCKED 
P 2  6  AUTO  DRA I 1)  VALVE  BAD  '( Y )', 

1  R2  l  AUTO  DRAl'i  VALVE  BAD  (N)  LEAK  IN  SW  SYS’lE 1 1 

HIGH  TEMP 

TANK 

- WATER  PRESS 

R50  WATER  TEMP  (Y l 

R51  WATER  TEMP  (tl)  OVERHEATED  FART 

B52_TEtjr_GAUGE 
R53  DEHYDRATOR  (Y)' 

R54  DEHYDRATOR  (II)  AJR  DEHYDRATOR 

LOW  WATER  COND  HIGH 

- | R61_ FW  SUPPLY  - , R69  HLDS  SUMP  DAD 

Y  R62  LOW  LEVEL  REFILL  Y  R70  DRAIN  BLOCKED 

R6 3  INU  SYS  LEAK  R7 1  AU10  DRAI M  VALVE  BAD 

?!  i  4  HANU/vL  DRAIN  OF  Ell  R72  AUTO  DRA1 N  VALVE  PAX)  (11) 

R65  AUTO  DRA1U  VALVE  DAD  " DEF LCtIve  wTrTmG 

RGG  AU'IO  REFILL _ BAD 

R 6  /  SEAL  FAILED  (  yT  ~ 

RGO  SEAL  FAILED  (II)  MASSIVE  LEAK 


ABNORMAL  UOISE 
N  Y 

R02 

no  PROBLEM 


The  Lpac  Troubleshooter  Decision  Tree  (part  2)  . 
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APPENDIX  B 


I.  AN  LPAC  TROUBLESHOOTER  CONSULTATION 

A.  OVERVIEW 

This  appendix  is  an  example  of  a  consultation  using  The 
LPAC  Troubleshooter.  The  figures  that  follow  are  similar  to 
the  actual  screen  displays  of  a  consultation  as  run  on  an  IBM 
AT  compatible  personal  computer.  In  this  appendix,  the  choices 
which  would  normally  be  highlighted  on  the  monitor  screen  have 
been  shown  in  bold  and  underlined  type . 

The  user  must  first  access  the  VP-EXPERT  program  from  DOS, 
and  then  consult  the  LPAC.kbs  file.  In  an  expanded  shipboard 
system,  there  could  be  a  separate  file  for  each  piece  of 
equipment,  each  with  its  own  KBS  extension.  For  the  purposes 
of  this  study,  there  is  only  one  file  available.  Once  the 
selected  file  is  loaded,  the  user  is  guided  through  the 
introductory  screens  and  then  begins  the  consultation.  The 
example  provided  in  this  appendix  is  a  consultation  for  a 
compressor  that  starts,  but  shuts  down  automatically  due  to  a 
high  water  level  cased  by  a  faulty  high  level  drain  switch. 
The  reader  may  also  find  it  helpful  to  refer  back  to  the 
decision  tree  provided  in  Appendix  A  to  trace  the  logic 
involved  in  each  question  of  the  consultation. 
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B .  THE  CONSULTATION 


Figure  Bl  is  VP-EXPERT's  opening  screen  when  executed  from 
DOS  with  the  executable  command  VPX.  To  begin  the  consultation 
the  user  can  select  4Consult  which  is  highlighted,  by  pressing 
either  4  or  Enter.  A  list  of  filenames  held  will  be  displayed 
(this  list  can  also  be  called  by  pressing  6Filename  from  the 
opening  screen)  as  in  Figure  B2 .  Each  application  written  in 
VP-EXPERT  is  categorized  as  a  "knowledge  base"  and  given  the 
extension  KBS.  If  applications  were  written  for  other 
equipment,  they  would  be  seen  here  if  they  reside  in  the  main 
program.  If  applications  are  stored  elsewhere,  they  can  be 
called  by  selecting  7Path,  and  specifying  the  drive  and 
directory.  For  The  LPAC  Troubleshooter  application,  the  user 
should  select  LPAC. KBS. 

Figure  B3  shows  the  intermediate  screen  as  the  file  is 
being  loaded,  and  Figure  B4  shows  the  blank  control  screen.  At 
this  point  the  user  selects  2Go,  which  is  highlighted,  by 
pressing  2  or  Enter.  Figure  B5  is  the  welcoming  screen,  and 
Figure  B6  introduces  the  user  to  the  system  and  gives  basic 
instructions  on  how  to  select  answers. 

Figure  B7  is  the  screen  for  the  first  question  which  the 
user  answers  Yes  to  show  that  the  compressor  starts.  Figure  B8 
shows  the  next  question  to  which  the  user  responds  Longer  to 
show  the  compressor  runs  longer  than  two  minutes.  In  Figure 
B9,  the  user  responds  Yes  to  show  that  an  automatic  shut  down 
has  occurred.  By  referring  to  Appendix  A,  it  can  be  seen  that 
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this  response  leads  into  the  Autoshutdown  branch  of  the 
decision  tree. 

Figure  BIO  shows  the  first  question  of  the  Autoshutdown 
branch,  and  the  user  has  indicated  No  for  the  high  temperature 
question.  In  Figure  Bll,  the  user  again  responds  No  to  the 
high  dew  point  question,  and  in  Figure  B12  high  water  in  the 
separator  holding  tank  has  been  identified  as  a  symptom  of  the 
problem.  Referring  back  to  Appendix  A  at  this  point,  it  can  be 
seen  that  this  response  leads  tc  a  separate  tree  for  high 
water.  In  the  program,  this  is  achieved  by  the  use  of  a 
separate  WHILETRUE  clause  in  the  ACTIONS  block.  When  Water 
Level=High,  then  this  clause  will  fire  a  separate  FIND  High 
Water  Solution. 

Figure  B13  instructs  the  user  to  continue  the 
troubleshooting  process  to  find  the  cause  of  the  high  water. 
Figure  B14  is  the  first  question  of  the  high  water  tree,  and 
the  user  responds  Yes  to  indicate  that  the  high  level  drain 
switch  is  defective.  Figure  B15  is  the  solution  to  the  problem 
instructing  the  user  to  replace  the  switch. 

In  this  particular  example  the  solution  may  appear  overly 
obvious,  but  the  value  of  these  systems  are  often  in  the 
preceding  questions  which  triggered  the  user  to  check  the 
switch.  Once  the  cause  of  the  problem  has  been  identified,  the 
solution  is  often  obvious.  This  particular  example  took  less 
than  one  minute  to  run,  and  the  longest  possible  example  has 
never'  taken  more  than  two  minutes.  In  actual  troubleshooting 
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cases  aboard  ship,  it  is  expected  that  consultations  could 
take  considerably  longer  since  the  machinery  itself  must  be 
checked  to  make  the  determinations  required  to  answer  the 


questions.  The  time  required  for  a  consultation  is 
to  be  well  within  the  20  minute  envelope 
appropriate  for  expert  system  applications. 


considered 

considered 


60 


VP -EXPERT 
Version  2.1 
Copyright  (c)  1988 
By  Brian  Sawyer 
All  Rights  Reserved 

Editor  Portion  Copyright  (c)  1984,1985,  1987,  Idea  Ware  Inc 


Published  by  Paperback  Software  International 


RULES 


FACTS 


lHelp  2lnduce  3Edit  4Conault  5Tree  6Filename  7Path  8Quit 
lHelp  2Go  3Whatif  4Variable  5Rule  7Set  8Edit  9Quit 


Figure  B1  VP-EXPERT's  opening  screen. 


VP -EXPERT 
Version  2.1 
Copyright  (c)  1988 
By  Brian  Sawyer 
All  Rights  Reserved 
Editor  Portion  Copyright  (c)  1984,  1985, 


1987,  Idea  Ware 


FILES 


Choose  a  file: 


LPAC . KBS 


lHelp  2lnduce  3Edit  4Consult  5Tree6Filename7Path  8Quit 
lHelp  2Go  3Whatif  4Variable  5Rule  7Set  8Edit  9Quit 


Figure  B2  VP-EXPERT' s  screen  listing  available  knowledge 
bases . 
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t  KBS : LPAC] 


Loading  file. . . 


RULES 

FACTS 

lHelp  2lnduce  3Edit  4Consult  5Tree  6Filename  7Path  8Quit 
lHelp  2Go  3Whatif  4Variable  5Rule  7Set  8Edit  9Quit 

Figure  B3  VP-EXPERT' s  intermediate  screen  while  loading 
program. 


lHelp  2Go  3Whatif  4Variable  5Rule  6Set  7Edit  8Quit 
lHelp  2How?  3 Why?  4Slow  5Fast  6Quit 

Figure  B4  Program  loaded  and  ready  to  run,  2Go  selected. 
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WELCOME  TO  THE  LPAC  TROUBLESHOOTER! 


Press  any  key  to  begin  consultation 


lHelp  2Go  3Whatif  4Variable  5Rule  6Set  7Edit  8Quit 
lHelp  2How?  3Why?  4Slow  5Fast  6Quit 


Figure  B5  The  LPAC  Troubleshooter  welcoming  screen. 


This  expert  system  will  help  you  troubleshoot  the 
NAXI  100-2  Low  Pressure  Air  Compressor.  You  will  be 
presented  with  a  series  of  questions  which  will  be 
used  to  find  the  solution  to  your  problem.  To  select 
an  answer,  use  the  cursor  keys  to  highlight  your 
choice,  press  enter,  and  then  the  end  key. 

Press  any  key  to  continue. 


lHelp  2Go  3Whatif  4Variable  5Rule  6Set  7Edit  8Quit 
lHelp  2How?  3Why?  4Slow  5Fast  6Quit 


Figure  B6  The  introduction  and  instruction  screen. 
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Does  the 

Yes 

compressor  start  when  manually  turned  on? 

No 

Enter  to  select  END  to  complete  /Q  to  Quit  ?  for  Unknown 


Figure  B7  The  first  question  with  yes  selected. 


Does  the  compressor  start  when  manually  turned  on? 
Yes  No 

How  long  does  the  compressor  run  before  stopping? 
3-5  Secs  2  Min  Longer 


Enter  to  select  END  to  complete  /Q  to  Quit  ?  for  Unknown 


Figure  B8  The  second  question  with  Longer  than  2  Min 
selected . 
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Does  the  compressor  start  when  manually  turned  on? 
Yes  No 


How  long  does  the  compressor  run  before  stopping? 
3-5  Secs  2  Min  Longer 

Has  compressor  automatically  shut  down  with  remote 
alarm? 

Yes  No 


Figure  B9  The  third  question  with  Yes  selected  for 
autoshutdown . 


How  long  does  the  compressor  run  before  stopping? 
3-5  Secs  2  Min  Longer 

Has  compressor  automatically  shut  down  with  remote 
alarm? 

Yes  No 

Is  the  compressor  air  discharge  temperature  above 
160 . deg? 

Yes  No 


Enter  to  select  END  to  complete  /Q  to  Quit  ?  for  Unknown! 


Figure  BIO  The  fourth  question  with  No  selected  for  high 
temp . 
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Has  compressor  automatically  shut  down  with  remote 
alarm? 

Yes  No 

Is  the  compressor  air  discharge  temperature  above 
160 . deg? 

Yes  No 

Is  the  dehydrator  dew  point  temperature  above  65  deg? 
Yes  No 


Enter  to  select  END  to  complete  /Q  to  Quit  ?  for  Unknown 


Figure  Bll  The  fifth  question  with  No  selected  for  dew  point. 


Is  the  compressor  air  discharge  temperature  above 
160 . deg? 

Yes  No 

Is  the  dehydrator  dew  point  temperature  above  65  deg? 
Yes  No 

Check  the  water  level  in  the  separator  holding  tank. 
Is  it  high  or  low? 

High  Low  Normal 


Enter  to  select  END  to  complete  /Q  to  Quit  ?  for  Unknovn 


Figure  B12  The  sixth  question  with  high  water  selected. 
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Press  any  key  to  conclude  consultation 


Figure  B13  Instruction  to  continue  troubleshooting  high  water. 


Is  the  high  level  drain  switch  in  the  holding  tank 

defective? 

Yes  No 


Enter  to  select  END  to  complete  /Q  to  Quit  ?  for  Unknown 


Figure  B14  Selecting  Yes  for  high  level  drain  switch 
defective . 
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Service  or  replace  high  level  switch. 


Press  any  key  to  conclude  consultation 


Figure  B15  The  final  screen  identifying  the  solution. 
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APPENDIX  C 


THE  SHIPBOARD  MAINTENANCE  DATABASE 

I.  OBJECT  DIAGRAMS 


EName 

Modelno 

— - -I 

system!  MV 


Manuf act 

Techman 

Number 


EQUIPMENT 


SName 

SDescript 


EQUIPMENT 

PROBLEM 

MV 

SYSTEM 


Task 

TDescript 


PROBLEM 


MV 


Procedure 

Parts 


CORRECTIVE 

PROCEDURE 


PName 

Symptom 

Cause 


MV  -  multivalued 


CORRECTIVE 

PROCEDURE 


SYSTEM 


PROBLEM 


Figure  Cl,:  Engineering  Maintenance  Database  System  object 
diagrams . 
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II.  OBJECT  SPECIFICATIONS 


A.  OBJECT  DEFINITIONS 

1 .  Equipment  Object 

EName;  Equipment  names 

Modelno;  Equipment  model  numbers 

SYSTEM;  SYSTEM  object;  SUBSET  [SNAME]  MV 

Manufact;  Manufacturer's  name 

Techman;  technical  manual  number 

Number;  number  of  units 

2 .  System  Object 

SName;  System  names 
SDescript;  System  purpose 

EQUIPMENT;  EQUIPMENT  object;  SUBSET  [EName] 

PROBLEM;  PROBLEM  object;  SUBSET  [PNAME]  MV 

3 .  Corrective  Procedure  Object 

Task;  Task  name 

TDescript;  Action  performed 

Procedure;  Corrective  procedures 

PROBLEM;  PROBLEM  object;  SUBSET  [PName]  MV 

Parts;  Equipment  parts  MV 

4 .  Problem  Object 

PName;  Problem  name 

Symptom;  Problem  symptoms 

Cause;  Cause  of  problem 

SYSTEM;  SYSTEM  object;  SUBSET  [SName] 

CORRECTIVE  PROCEDURE;  CORRECTIVE  PROCEDURE  object, 
SUBSET  [Task] 
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B .  DOMAIN  DEFINITIONS 


1 .  Cause 

Text  100 

What  is  causing  the  problem 

2 .  EName 

Text  30 

Name  of  a  specific  piece  of  equipment 

3.  Manufact 

Text  30 

Name  of  the  manufacturer 

4 .  Modelno 

Text  15 

Unique  alpha-numeric  combination  identifying  the 
equipment 

5 .  Number 

Numeric  2 

The  number  of  units  of  an  equipment  found  aboard  ship 

6 .  Parts 

Text  100 

A  list  of  parts  required  to  perform  the  task.  Each 
part  given  by  technical  manual  figure/index  number. 

7 .  PName 

Text  50 

The  name  of  the  problem  in  a  piece  of  equipment 

8 ..  SDescript 

Text  250 

A  brief  description  of  the  purpose  and  function  of  a 
system 

9 .  SNaxne 

Text  30 

Name  of  a  system  found  in  a  piece  of  equipment 

10.  Symptom 

Text  100 

A  description  of  the  symptoms  of  the  problem 

11.  Task 

Text  30 

The  corrective  maintenance  job  to  be  performed 
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12 .  TDescript 

Text  100 

A  brief  description  of  the  task 

13 .  Techman 

Text  1 6 

An  alphanumeric  combination  of  the  NAVSEA  technical 
manual  number 

14 .  Procedure 

Memo 

This  field  references  a  separate  text  file  containing 
the  detailed  steps  to  perform  a  corrective  maintenance 
task. 
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III,.  DATAFLOW  DIAGRAMS 
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t&cwml  EQUIPMENT  OBJECT 

7G$ 


ua* 


N\ 

\ 


TECH 

^»i.7<V^vVr-1 *V: 

r 

MAW  <AL 

L 

><€# 

■AfiOffbV 


\  /  mg&fy  \ 

r  J  v^ftUlFMENT/ 


V\  /  DELETE  \ 
|Eft'l|PMENT} 

V  r 

\.  y 


vA HWfi? 


£*>«}*3MEVr 
r'&j&rT 
/iw-'t, rr* 


EN^INEBUNS  MANTEU-W  C€ 

_ ^T&OAafi _ 


Figure  C3  The  EQUIPMENT  Object  Dataflow  Diagram. 
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Figure  C4  The  SYSTEM  Object  Dataflow  Diagram. 
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Figure  C5  The  Corrective  Procedure  Object  Dataflow  Diagram 
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Figure  C6  The  PROBLEM  Object  Dataflow  Diagram., 
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IV.  UPDATE,  DISPLAY  AND  CONTROL  MECHANISMS 


A.  LEADING  PETTY  OFFICER  APPLICATION 

1 .  Update  Mechanisms 

a.  Add  EQUIPMENT ,  SYSTEM ,  CORRECTIVE  PROCEDURE ,  and 
PROBLEM  Data 

(1)  Inputs.  New  equipment  technical  manuals. 

(2)  Outputs.  New  EQUIPMENT,  SYSTEM,  CORRECTIVE 
PROCEDURE,  and  PROBLEM  object  instances  in 
database. 

(3)  Frequency.  As  new  equipment  arrives. 

Jb.  Edit  EQUIPMENT,  SYSTEM,  CORRECTIVE  PROCEDURE,  and 
PROBLEM  Data 

(1)  Inputs.  Technical  updates  from  NAVSEA. 

(2)  Outputs.  Modified  object  instances  in  the 
database . 

(3)  Frequency.  As  updates  are  received. 

2 .  Display  Mechanisms 

a.  Query  on  EQUIPMENT,  SYSTEM,  CORRECTIVE  PROCEDURE, 
and  PROBLEM 

(1)  Output  Description.  Forms  showing  all  object 
data . 

(2)  Source  Data.  Objects;  equipment,  system, 
corrective  procedure,  or  problem  names  keyed  in  by 
user. 

(3)  Processing  Notes.  Used  by  LPO,  CPO,  or  DIVO. 

(4)  Frequency.  As  required. 

Jb.  Equipment  Technical  Manual  List 

(1)  Output  Description.  A  report  showing  all 
EQUIPMENT  object  instances  and  their  respective 
tec’  .lical  manuals. 

(2)  Source  Data.  EQUIPMENT  object;  keyed 
request  for  equipment  report . 

(3)  Processing  notes.  Used  to  validate 
technical  library. 

(4)  Frequency.  Quarterly. 

3.  Control  Mechanism  -  access  by  password. 
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B.  TROUBLESHOOTING  APPLICATION 


1.  Update  Mechanisms  -  none. 

2 .  Display  Mechanisms 

a.  Query  on  EQUIPMENT SYSTEM,  COfXECTIVE  PROCEDURE, 
and  PROBLEM 

(1)  Output  Description.  Forms  showing  all  object 
data. 

(2)  Source  Data.  Objects;  equipment,  system, 
corrective  procedure,  or  problem  names  keyed  in  by 
user. 

(3)  Processing  Notes.  Used  by  LPO,  CPO,  or  DIVO. 

(4)  Frequency.  As  required. 

Jb.  Problems  by  Symptom  Report 

(1)  Output  Description.  A  report  showing  all 
problems  for  a  given  symptom  and  their  corrective 
procedure  tasks. 

(2)  Source  Data.  CORRECTIVE  PROCEDURE  and 

PROBLEM  objects;  keyed  request  for  problems  by 
symptom  report . 

(3)  Processing  Notes.  Used  by  maintenance 
technician  for  troubleshooting  equipment. 

(4)  Frequency.  As  required  to  troubleshoot. 

c .  Problems  by  System  Report . 

(1)  Output  Description.  A  report  showing  all 
problems  for  a  given  system  and  their  corrective 
procedure  tasks. 

(2)  Source  Data.  SYSTEM,  CORRECTIVE  PROCEDURE 
and  PROBLEM  objects;  keyed  request  for  problems 
by  system  report . 

(3)  Processing  Notes.  Used  by  maintenance 

technician  for  troubleshooting  equipment. 

(4)  Frequency.  As  required  to  troubleshoot. 

d.  Corrective  Procedure  Report 

(1)  Output  Description.  A  report  showing  the 
corrective  procedure  for  a  problem. 

(2)  Source  Data.  CORRECTIVE  PROCEDURE  and 

PROBLEM  objects;  keyed  request  for  corrective 

procedure  report . 

(3)  Processing  Notes.  US'  d  r y  maintenance 

(technician  for  troubleshooting  equipment. 

(4)  Frequency  -  as  required  to  troubleshoot. 
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III.  RELATIONAL  DIAGRAM 


I 


Techman  Number 


SYSTEM 


SName  SDescript  EName* 


CORRECTIVE  PROCEDURE 


Symptom 

Cause 

SName* 

Task* 

Figure  C7  Engineering  Maintenance  Database  System 


Table  Cl.  Relation  Definitions 


EQUIPMENT 


SYSTEM 


CORRECTIVE 

PROCEDURE 


I  PROBLEM 


EName 


30  t  SName 


30  t  Task 


Modelno  15  t  SDescript  250  t|TDescript  100  t 


Manufact  30  t  jEname 
Techman  16  t i PName 


30  t  PName  50  t  Cause  100  t 

50  t  Procedure  U  m  Task  50  t 

Parts  100  t  SName  30  t 


Number  2  n  Parts  100  t I SName  30 

[_ _ [_  |  |, _ J _ j _ _j _ !__J _ _ _ J_ 

L=LENGTH  T=TYPE  t=Text  r.=Numeric  U=Unlimited  m=Memo 


30  t 


PName  50  t 
Symptom  100 jt 


VI.  FORMS,  REPORTS  AND  MENUS 


EQUIPMENT  DATA 

XXXXXXXXXXXXXXXXXXX 

xxxxxxxxxxxxxxxxx  xxxxxxxxxxxxxxxxx 

NAME 

MODEL  NUMBER  MANUFACTURER 

XXXXXXXXXXXXXXXXXXXX 

XXX 

TECHNICAL  MANUAL 

NUMBER  ONBOARD 

SYSTEM  DATA 

XXXXXXXXXXXXXXXXXXXXX  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

NAME 

DESCRIPTION 

CORRECTIVE  PROCEDURE 

DATA 

XXXXXXXXXXXXXXXXXXXXX  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

TASK 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxx 

DESCRIPTION 

PROCEDURE  (MEMO) 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

PARTS 

PROBLEM  DATA 


XXXXXXXXXXXXXXXXX  xxxxxxxxxxxxxxx  xxxxxxxxxxxxxxxxxxxxx 
NAME  SYMPTOM  CAUSE 


Figure  C8  Leading  Petty  Officer  Update  Forms. 


Enter  name  of  EQUIPMENT  to  delete:  XXXXXXXXXXXXXXXXXXXXX 
This  is  the  record  for  the  equipment: 

XXXXXXXXXXXXXXXXXXX  XXXXXXXXXXXXXX  XXXXXXXXXXXXXXXXXXXX 
Equipment  name  Model  number  Technical  manual 

Is  this  the  correct  equipment  to  delete?  (Y/N) 

Figure  C9  Form  for  Deleting  EQUIPMENT. 
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PROBLEMS  BY  SYSTEM 


SYSTEM  PROBLEM  CORRECTIVE  PROCEDURE 

PROBLEMS  BY  SYMPTOM 

SYMPTOM  PROBLEM  CORRECTIVE  PROCEDURE 

Figure  CIO  Troubleshooting  Reports  of  Problems 


TASK: 

DESCRIPTION: 

PROBLEMS  CORRECTED: 
PROCEDURE : 

PARTS  REQUIRED: 


Figure  Cll  Troubleshooting  Corrective  Procedure  Report. 
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Table  C 2 .  Database  Schema . 


DATA  \  APPLICATION 

LEADING  PETTY 
OFFICER 

TROUBLESHOOTING 

EQUIPMENT 

X 

SYSTEM 

X 

X 

CORRECTIVE 

PROCEDURE 

X 

X 

PROBLEM 

X 

X 

MAIN  MENU 

1.  LEADING  PETTY  OFFICER  APPLICATION 

2.  TROUBLESHOOTING  APPLICATION 

3.  EXIT 


Figure  C12  The  Engineering  Maintenance  Database  Main  Menu, 


[ _ 


LEADING  PETTY  OFFICER 

1.  Equipment  data. 

2.  System  data. 

3.  Corrective  Procedure  data. 

4.  Problem  data. 


Figure  C13  The  Leading  Petty  Officer  First  Level  Menu, 
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1 


EQUIPMENT 

1 .  Add  new  equipment . 

| 

2.  Modify  existing  equipment. 

3.  Delete  equipment. 

i 

4 .  Browse  equipment .  j 

I 

5.  Print  equipment  list. 


Figure  C14  The  Leading  Petty  Officer  Second  Level  Menu  for 
Equipment . 


TROUBLESHOOTING 

1.  Problem  data. 

2.  Corrective  Procedure  data. 


Figure  C15  The  Troubleshooting  Application  First  Level  Menu 
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CORRECTIVE  PROCEDURES 


1.  Browse  records. 

2.  Print  selected  record. 


Figure  C16.  The  Second  Level  Troubleshooting  Menu  for 
Corrective  Procedures. 


PROBLEMS 

1.  Browse  problem  records. 

2.  Print  selected  problems. 

3.  Display  problems  report. 

4.  Print  problems  report. 


Figure  C17  The  Second  Level  Troubleshooting  Menu  for  Problems. 


« 
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DISPLAY  PROBLEMS  REPORT 


1.  Problems  by  system. 

2.  Problems  by  symptom. 


Figure  C18.  The  Third  Level  Troubleshooting  Menu  for  Display 
Problems  Report. 
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